DB设计-泛型关系？(relation_id，relation_table)
我最近加入了一个有积分系统的项目。你可以通过购买来获得积分，但也可以通过替换代码来获得分数。
每次给定一组点时，都会在a“points”表中创建一行，跟踪已给出这些点的用户、时间、数量等。
我们也在追踪分数是如何给出的。即编码还是购买？
目前，数据库的结构为(简化我的问题)：
id | relation_id | relation_table | user_id
--------------------------------------------
30 | 42400 | coupon | 1
31 | 39812 | payment | 1我能想到的唯一的名字是“一般关系”，但我从来没有见过这样的情况。
因为一次只有一段关系是活跃的，我觉得这是可以接受的。
我真的觉得很奇怪，我也不确定我会这么做。
这个数据库设计有更好的选择吗？
是拥有以下内容的更好的选择。
id | payment_id | coupon_id | user_id在编程中，我可以理解为什么前者更容易使用，但它只是不适合我。
谢谢
编辑：
id将是主键& AI和user_id将是引用用户表的外键，跟踪哪个用户拥有哪个硬币条目。
回答 2
Stack Overflow用户
发布于 2016-08-17 19:14:23
我不知道id在您的表中意味着什么，因为您已经拥有了user_id，它是外键吗？
跳过我的上述问题，我建议和前一个一起去。
user_id, relation_id, relation_type, id, points
1 2345 coupon 3 56
6 789 payment 96 78因为在后面的例子中，您无法跟踪relation_type，所以当您想了解为什么特定用户给出了x点数等时，这一点就变得更加重要了。
我们也在追踪这些分数是如何给出的。即代码还是购买？
因此，如果您真的想跟踪点，您必须知道类型代码或购买。
因为一次只有一段关系是活跃的，我觉得这是可以接受的。我真的觉得很奇怪，我也不确定我会这么做。这个数据库设计有更好的选择吗？
它是一种布尔(购买(0)或优惠券(1))，是的，只有一个关系会在一次活动。但这完全没问题。你必须创建两个不同的纯追踪跟踪表和优惠券跟踪器，这看上去很奇怪。这也违反了正常化规则。
Stack Overflow用户
发布于 2016-08-18 14:33:16
这种数据库设计有其自身的优点。从一个点开始，您可以通过"relation_id，relation_type“metalink为其他类型的点扩展源。不确定你需要改变它。
https://stackoverflow.com/questions/39001246
复制相似问题
腾讯云开发者
