数据库设计 - 通用关系？ （relation_id，relation_table）

Question

我最近加入了一个拥有积分系统的项目。您可以通过购买获得积分，但您也可以通过兑换代码来赚取积分。

每次给出一组点，就会在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将是主要关键字＆amp; AI和user_id将是引用用户表的外键，跟踪哪个用户拥有哪个硬币条目。

Answer 1

由于您已经拥有 user_id ，我不知道 id 在您的表中是什么意思，是外键吗？

跳过上述问题，我建议选择前一个问题。

user_id, relation_id, relation_type, id, points
1          2345         coupon        3    56
6          789          payment       96   78

因为在后一个版本中，你无法跟踪relation_type，当你想知道特定用户为什么给出x个点等时，这就变得更加重要。

我们也在追踪得分如何。即代码或购买？

因此，如果您真的想跟踪积分，您必须知道类型代码或购买。

由于一次只有一个关系活跃，我觉得这有点可以接受。我认为这很奇怪，我不确定我会这样做。这个数据库设计有更好的选择吗？

它是一种布尔值（购买（0）或优惠券（1）），是的，一次只有一个关系是活跃的。但那完全没问题。您将不得不创建两个不同的购买跟踪器和优惠券跟踪器，这对我来说很奇怪。这也违反了规范化规则。

Answer 2

这种数据库设计有自己的优势。从一点开始，您可以使用单个表进行积分计算，从其他方面来说，您可以通过＆＃34; relation_id，relation_type＆＃34;来扩展其他类型积分的来源。 Metalink上。不确定你需要改变它。