我最近加入了一个具有积分系统的项目。您可以通过购买赚取积分，也可以通过兑换代码赚取积分。
每次给出一组积分时，都会在“积分”表中创建一行，跟踪获得这些积分的用户、时间、数量等。
我们还在跟踪积分的授予方式。即代码或购买？
目前数据库的结构如下(针对我的问题进行了缩减):
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 将是引用用户表的外键，跟踪哪个用户拥有哪个代币条目。
最佳答案
我不知道 id 在您的表中代表什么，因为您已经有 user_id，它是外键吗？
跳过我的上述问题，我建议选择前一个问题。
user_id, relation_id, relation_type, id, points
1 2345 coupon 3 56
6 789 payment 96 78
因为在后一个中，您无法跟踪关系类型，当您想了解为什么特定用户给出了 x 个分数等时，这一点变得更加重要。
我们还在跟踪积分的授予方式。即代码或购买？
因此，如果您确实想跟踪积分，您必须知道类型代码或购买。
由于一次只有一种关系处于活跃状态，我觉得这还算可以接受。我确实觉得这很奇怪，而且我不确定我是否会这样做。这个数据库设计有更好的选择吗？
它是一种 bool 值(购买(0)或优惠券(1))，是的，一次只有一个关系处于事件状态。但那完全没问题。您必须创建两个不同的购买跟踪表和优惠券跟踪器，这对我来说看起来很奇怪。这也违反了规范化规则。
关于mysql - 数据库设计 - 通用关系？ (关系 ID，关系表)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39001246/