Database design 使用联接表与类型字段的权衡

我正在深入了解如何使用一个与多个其他表相关的表来设计数据库。一个具体的例子是一个对不同事物发表评论的网站——人们可以对文章发表评论，也可以对照片发表评论，也可以对人发表评论

似乎有两种方式来表示这一点：

1） 为每个表连接表 表：

• 文章
• 文章和评论
• 评论
• 人民的意见
• 评论和照片
• 人
• 照片

或 (二)

• 文章
• 评论
• 人
• 照片

注释表将有一个“type”字段和一个item_id链接回另一个表

第一种方法似乎更“合适”，使用外键约束似乎没有问题，而第二种方法的表更少，在某些方面可能更“简单”，但我们可以使用FK约束，因为item_id可以与多个FK相关（AFAIK-使用mysql innodb）。在我们的应用程序中，可能有2-3个表具有多个关系（注释、照片等），5-10个表需要关系，这可能是一件好事

---

我正在寻找哪种方法更好的建议。

带有

type

列的

comment

表（enum btw）似乎是更好的方法，因为您可能希望在将来改进“comment”是什么

有了如您所描述的四个表，模型类字段和它们之间的关系也会变得更容易

如果是0对多关系，则对注释表使用“左联接”。否则它就是一个“内部连接”

---

享受。

我个人不喜欢选项2。它代表了一个有争议的话题，一个大的查找表概念

首先，我同意Yzmir-icky的管理方法。此外，它还代表了在关系数据库的设计中使用OO，这有点像苹果和橙子的混合。虽然有OO编程背景的人（包括我……）很容易想象一个“注释对象”及其属性，但请考虑一下DB设计。示例1中的表名清楚地描述了它们所表示的实体以及它们之间的关系（多对多引用表）中的实际情况。它们也代表了对“正常”形式更好的坚持

RBDM是关于表示实体及其之间的关系的，并不一定总是符合OO的原则。此外，规范化规则更倾向于选项1

---

选项#1对我来说代表了更强的RDB设计，并且更易于管理、更易于扩展，并且可能执行得更快

方法2非常难以手动管理。必须跟踪“来源”和关系键，并且没有建立关系的好方法。如果您使用的是像Hibernate这样的框架，它通过区分表支持子类，那么它可能是“可行的”（例如，永远不要直接处理它）。但是，我更喜欢#1，因为它确实更“适合SQL模型”，即使SQL DDL不允许对分布式密钥进行良好编码：（[对于挑剔的人，可以使用约束和复合引用。]注意-在经历了更多的生活和学习之后，我将选择的答案更改为Yzmir Ramirez提供的答案。我认为，必须处理不同的注释表要糟糕得多。概念概念的更改必须在多个地方进行，删除成员需要搜索更多的表并跟踪它们，一个lso向注释添加功能（例如附加多个媒体对象）变得更加复杂。另外，我使用诸如comment_people之类的视图使简单的活动记录类型ORM更易于使用-即“表”只有单一类型。谢谢-关于FK问题呢-你是在代码中处理还是用触发器处理？另外，FWIW-我认为使用活动记录类型的orm，他们将直接了解使用第一种方法很少/没有配置的关系。我认为第二种方法需要更复杂的orm（或手动处理）