Hej all，
假设我有4个名为“user”，“office”，“product”，“event”的表。 另一个名为“文档”的表。可以分配相同的文档 一个或多个用户，办公室，产品和活动。所以我们需要一个 多对多的关系。但我有3种方法可以做到这一点：
- 一个名为“user_document”的表，另一个名为“office_document”，“product_document”和“event_document”的表都有一个名为 “document_id”，它是文档ID和另一个字段的外键 “user_id”（对于user_document），它是用户id的外键（等等） 当然还有办公室，产品和活动......）
OR
- 名为“document_ownership”的表，其中包含以下字段：“document_id”，“user_id”，“office_id”，“product_id”和“event_id”。 这里document_id应该不是Null和一个（或多个）其他字段 这可能是空的。例如，如果我为用户设置了相同的文档 一个产品，我将有一行document_id，user_id和product_id 不是空的。
OR
- 一个名为“document_ownership”的表，它将包含以下字段：“document_id”，“relation_type”和“relation_id”。这里是relation_type 字段例如是字符串（表示关系表） name）或指向另一个为其命名的附加表的外键 例如“relationtype”，其中我们有像“user”（id = 1）这样的字符串， “office”（id = 2），“product”（id = 3）和“event”（id = 4）（也是 表示关系表名称），relation_id表示id 指定的关系表（relation_type）
我的问题是，所有这3种做我想做的方式的利弊是什么，最佳做法应该是什么？
提前感谢您的建议，
米甲
答案 0 :(得分：1)
这个问题实际上并没有得到回答。纯粹主义者会说方法1是正确的，但并不总是这么简单。可以这样想 - 您的数据库设计应表达数据与数据含义之间的关系。因此，您的每种方法都意味着有关数据性质的几个方面。
方法1说用户，办公室，产品和活动很重要，哦，是的，他们可以有文件。也许
方法2说文档很重要，我们需要跟踪每个文档的相关内容。因此，文档是关键的事情，其他一切都是围绕着这个。
方法3更加复杂和技术性，并没有真正了解您希望如何使用数据。
在所有情况下，数据都是相同的。它只是设计数据来讲述它应该如何使用的故事。
抱歉抒情。只需我0.02美元。
答案 1 :(得分：0)
在数据概念（Merise）视图中，您有：
文献-0，N 0 ---------，正用户
文献-0，N 0 ---------，正事件 ...
这是逻辑观点。
当您将其转换为物理数据视图时，每个关系最终会有1个表。
因此，如果您想在数据模型中应用最佳实践，那么第一种解决方案就是可行的方法。
关于另外两个破坏正常形式的解决方案：