数据库设计：简化多对多答案

【问题标题】：Database Design: simplifying many to many数据库设计：简化多对多
【发布时间】：2011-04-09 12:06:21
【问题描述】：

假设我有以下表格：

人（person_id，姓名）
种族（ethnicity_id，姓名）
person_ethnicity（person_id、ethnicity_id）

这将允许我通过person_ethnicity 表定义一个person 以拥有0 个或多个ethnicity 和一个ethnicity 以拥有0 个或多个person。

现在，假设我有很多这些“种族”类型的表，我必须与person 表建立相同的多对多关系。我的桌子数量会增长得非常快。

换成这样的表格是不是个好主意：

foo (person_id, other_table_name, other_table_pk)

一个例子：

=================================================
| person_id | other_table_name | other_table_pk |
=================================================
| 1         | ethnicity        | 1              |
-------------------------------------------------

我以这种方式失去了参考完整性，但我认为建模会更容易。这种方法是一个好主意还是一个可怕的、可怕的主意？

（另外，我上面描述的方法有合适的名称吗？）

【问题讨论】：

您是否打算与种族以外的人建立多种其他关系？我问是因为您的第二个解决方案似乎您计划将多个表/ID 联合起来。
@Khez - 是的，如我最初的帖子中所述。
您描述了一个人和一个关系种族。然而，您的第二个解决方案意味着拥有其他关系，例如国籍。如果不是这种情况，那么您的第二个解决方案是一个非常糟糕的主意。
@Khez - 我还描述了我有很多需要建模的种族类型表。
我不是唯一一个想念它的人......我责怪互联网幽灵。

标签： mysql database innodb database-design

【解决方案1】：

我认为没有必要。很多表都没有问题，你这样做违反了很多“规则”。如果需要，只需使用多对多即可。

以这种方式使用它你应该做各种棘手的事情。此外，你不能用外键（约束）和大量其他问题做任何事情。为了什么？ “更少的桌子”。我没有看到任何优势：D

不要成为我的建议：D

【讨论】：

【解决方案2】：

既然你是从理论的角度来问这个问题，我会在同样的方面给你一个答案。

您的情况与标签系统非常相似。幸运的是，MySQL 社区提供了一篇关于 TagSchema via Forge 的优秀 wiki 文章。

您还应该考虑在 SO 中搜索类似问题，因为它是 asked 和 asked 和 asked。其中一些实际上提供了对此事的有趣见解。尤其是What tag schema(s) are the most efficient/effective? 以及对持有Tag Sets 的Collection Tags 的响应。

【讨论】：

【解决方案3】：

如果您的模型中有很多多对多关系，例如您的种族示例，那么您别无选择，只能按照关系习语要求的方式正确建模它们。

我不认为你的设计是个好主意。绑定到表名和列名不是在 Java 中完成的。我不知道其他语言。

拿一把铲子；开始工作。使用关系习语对存在的问题进行建模或查找其他内容。在您的情况下，也许像对象或图形数据库这样的 NoSQL 解决方案是一个更好的主意。

【讨论】：

我不会有很多种族表。我有许多类似种族的表（意思是，需要与 person 表的多对多关系）。我不明白您对 Java 的引用，因为我是从数据建模的角度提出问题的。
@StackOverflowNewbie ...您最初的帖子并没有暗示这一点，但您的解决方案却暗示了这一点。
对不起，错过了“种族”位。我会修改。而且我知道这是关于关系建模的，但最终我假设您将编写一个必须访问您的模式的应用程序。当你这样做时，你将不得不处理选择的语言。 AFAIK，您不绑定表名和列名，只绑定值。

【解决方案4】：

您的解决方案会很快炸毁您的“foo”表。

假设您有 1000 人。那么每个人至少有2个种族。

那么你有一个国籍表，每个人也至少有 1.5 个国籍。

然后是一个性别，其中每个人至少有 1 个性别，总共有 4500 个条目。

现在假设您的人员表增长到大约 50000 人。

这将使您的“foo”表中已有 225000 个条目。

现在您的表格已填满，您可以使用 foo 和 only 种族进行查询，以获取所有人的种族，并且您的服务器将工作非常长，因为您将 50000 表格与 225000 表格连接在一起，并且在end 加入一个小表。

所以我希望我能说清楚为什么做这样的布局不是个好主意

【讨论】：