Database 数据库设计，多个M-M表还是一个？

今天我正在为我的一个潜在的个人项目设计一个数据库。因为我不能决定什么是更好的选择，我问了我的老师，不幸的是，他不能告诉我这两个选择中哪一个比另一个好，为什么

我为一个虚拟数据生成器设计了数据库。因为我想生成多语言数据，所以我想到了这些表。（但这只是表格的简化）

（第一个和最后一个）名称：id，名称
街道：id、名称
语言：id、名称

每个names.name和streets.name来源于一种语言，有时一个名称可以有多个来源（例如：Nick的英文名称都是荷兰语）。
每种语言都有多个名称和街道

这两条规则导致多对多关系。目前我只有两张桌子，但我知道我会得到10到20张这样的桌子。
通常的做法是创建10到20个多对多关系表。
我提出的另一个想法是，只有一个多对多表，第三列指定id与哪个表相关

目前我已经在我的另一台电脑上安装了这个设计，所以我会在晚饭后（2小时左右）用我的想法来更新它

哪个主意更好，为什么

---

为了让项目思路更清晰一点：
为项目创建良好且足够逼真的工作数据总是一件麻烦事。此应用程序将为您生成此数据并返回所需的SQL，因此您只需运行查询

用户来到站点获取数据。他陈述了他的表名和列名，然后他可以将列名链接到数据类型，想想：
*名字
*姓氏
*电子邮件地址（将根据此人的姓名随机生成）
*地址详细信息（街道、门牌号、邮政编码、地点、国家）
*更多

---

然后，在将列与类型链接之后，用户可以设置要生成的行数。然后应用程序将随机选择一个国家，并根据他们居住的国家生成逼真的数据。

这实际上是一个很好的问题。这类事情导致了数据库设计中的一个真正的问题，这是一个真正的权衡。我不知道您正在使用什么rdbms，但是

基本上你有四种选择，都有严重的缺点：
1.一个M-M表格，带有检查约束，除了语言和每个潜在表格一列外，只能填写一个fkey。点击……
2.每个关系一个M-M表。随着时间的推移，这使得事情变得很难管理，特别是当您需要在某个时刻将某些内容从int更改为bigint时。
3.一个具有多态关系的M-M表。在执行此操作时，会丢失大量引用完整性检查，为了确保安全，请享受编写（和测试！）触发器的乐趣。
4.仔细查看rdbms中的高级功能，以获得解决方案。例如，在

postgresql

中，这可以通过表继承来解决。缺点是您失去了可移植性，最终进入了高级领域

不幸的是，没有一个明确的答案。你需要仔细考虑权衡，决定什么对你的项目有意义。如果我只使用一个RDBMS，我会使用最后一个。但如果不是，我可能会为每个关系创建一个表，并将重点放在管理出现的问题的工具上。但前者是关于我的知识水平和信心，而后者则更多的是个人观点

---

因此，我希望这有助于您权衡利弊，选择适合您的方案。

谢谢您的回答，我现在向您投了赞成票，我们将利用您获得的信息进行更多的研究。稍后我会将它标记为答案（如果没有其他人给出更明确的信息），我只是阅读了上面提到的选项，我想我会选择选项3。我计划使用Laravel，它有一些很好的工具来处理M-M多态关系。也许我遗漏了什么，但我看不出你的问题。m-n关系似乎介于名称和语言之间。街道有一个与名字相关的名字。如果需要名称的语言，请使用现有的m-n关系。因此，如果您创建一个Cities表——当然，它有一个名称——该名称还与Names表相关，依此类推。名字和语言之间有一种关系。所有使用名称的实体都可以使用这种关系，它们不需要自己的关系。名称（名字和姓氏）表和街道名称表之间没有关系。我应该在问题中说得更清楚些，这没有道理。名字和姓氏是人（客户、员工、客户等）的属性，不要放在单独的表中。在他们自己的表中放置名称的唯一时间是提供关于名称的其他数据，例如源语言。如果街道中有一个属性指定了另一个属性的语言，则存在规范化问题。如果您通过交叉表指定此关系，那么您也可以为名称实体创建名称表，并定义每个名称/语言关系一次，然后使用它。我正在创建一个数据库以生成虚拟数据，为此我将从数据库中随机选择一个国家，查看该国家使用的语言并使用名称，地址和来自这些语言的其他信息。因此，我不是在保存人员，而是在创建随机数据时使用的名称，我将这些数据导出为SQL，以便其他人可以使用我的应用程序生成的虚拟数据。我刚刚编辑了我的问题，它现在也包含了对项目的更好描述。