3

可以说我有书和人。一个人可以写很多本书，一本书可以由很多人写。一个人读过很多书，一本书被很多人读过。

Person               Book
------               -----
personId             bookId

我可以使用两个关系表：

has_read             has_authored
--------             ------------
personId, bookId     personId, bookId

或者一个：

person_book_relation
--------------------
personId, bookId, relationType ("read", "authored")

另一个示例可能是 Actor 和 Event 之间的某种订阅者/发布者关系。

有什么指导方针可供选择吗？

如果有更多类型的关系怎么办？这会改变你的解决方案吗？

一个团队有很多人扮演一个角色。一个人可以在多个团队中。（只是编造这个）

Team_Person_relation
--------------------
TeamId, PersonId, Role ('Defender', 'Attacker', 'Goalkeeper', 'Midfielder'... etc)

如果您要使用单独的表，这将至少是 4 个表。但是，感觉团队角色之间的联系比“阅读/撰写”关系更紧密？

4

2 回答 2

3

我会使用第二种类型的表，除非我遇到关系类型实际上影响表中的列的情况。

例如，在图书示例中，作者可能有一个日期，将其发送给出版商，这使得将所有信息保存在一个表中的想法无效，因为该信息不适用于读者。

同样，“进球得分”仅适用于您的守门员。

我想诚实的，如果有些陈词滥调的回答是“这取决于您要提取的信息”-但通常，您可以越明确地表明“这是描述表 x 和表 y 之间关系的表”越清楚并且更容易维护您的数据库。

于 2012-08-30T22:20:41.903 回答
1

作为数据库创建者，这主要取决于您，因为这两种解决方案都是正确的。应该考虑的主要是数据将在未来如何使用（或至少现在预测如何使用）。一些例子：

  1. 如果您在一张表中强制使用太多多对多关系，则在使用其中一个表时，您需要始终记住“那里还有其他关系”。例如，如果您希望查看所有未创作任何书籍的人，您需要以过滤“已读”关系的方式构建左连接查询。随着您的查询变得更加复杂并包含更多表和更多外部连接，很容易获得不需要的结果。

  2. 团队角色的示例表明角色列表将来可能会发生变化。因此，将此角色保留在关系列中是更好的解决方案。此外，这里的关系指定“成为团队的成员”，并且该成员的角色只是该成员的财产。

  3. 如果您希望通过多对多关系存储一些附加信息（例如创作日期，或读者喜欢这本书的程度），它将建议单独的表，否则将使用许多稀疏列来处理所有可能的关系.

  4. 最后但同样重要的是：性能。如果表试图包含太多“不相关”的数据，有时可能很难有效地设计和使用索引。

于 2012-08-30T22:27:20.103 回答