我有一个很基本的问题，让我困惑一些奇怪的原因。一对多vs多对多的关联设计和好处
我有两个表，一个是表页，另一个是菜单。我想知道，使用另一张表进行映射有什么好处？下面是两个实现，我想：
我看到的唯一区别是，我的搜索方式。 例如在第一个实现中：
a）如果我想要一个特定菜单的所有页面，我将查询特定菜单名称的所有page_id，然后我将它们与表格的页面ID （这就是为什么我认为这个实现更慢）。
b）如果我想要一个特定页面的所有菜单，我将搜索所有具有特定页面的page_id的菜单。
在第二个实现是更典型和直接（并与更多的连接）。我认为第二个实现是正确的，因为它更快（我猜，因为它只查询id之间的索引，而不是在菜单名称中搜索，如我在上面a）中所述）。
或者是否还有其他特殊原因？这两种设计在他们所能完成的事情上是相同的，还是在第一种设计中有其他限制，我总是应该选择第二种设计？
这两个选项并不相同;后者是在多对多设计中使用的正确选择。使用连接表意味着可以有许多页面（A，B，C）和许多菜单（1,2,3），并且可以将一组菜单与一组页面关联（产生A1，A2，A3，B1 ，B2，B3，C1，C2，C3）。
第一种设计假定任何给定的菜单只能有1页与其关联。菜单1只能与一个页面关联（是A，B还是C？）。要将相同的菜单与多个页面相关联，您需要在菜单表中为每个关联页面设置一行。
你的第一个实现是1对多，不是多对多。你的第二个实现是多对多的有效载荷（注意：它通常不需要一个id）。
多对多意味着您可以将n个项目映射到n个其他项目。 1到很多意味着你只有一个项目映射到n个项目。
如果您需要多对多，只能在您的第二个实施中完成。如果你需要1到很多，那么完成第一种方式。
页面和菜单有多对多的关系。问题是，除了关系的简单事实之外，是否还有关于您需要追踪的关系的任何信息？
例如，如果您发布了杂志，您可能会有一个人< - >杂志关系是M2M - 人们可以订阅多个杂志，杂志可能有多个订阅者。但是有关于杂志和您想跟踪的人的交集的信息 - 开始日期，到期日期等。使用交集表给你一个放置它们的地方。
我一直在做这种东西一段时间，我可以想到有相当数量的实例，我有一个M2M，除了存在交集之外，交集没有任何记录，因为系统最初实施。然而，在几乎所有情况下，用户后来都要求进行改进，这需要关于关系的更多信息。
所以我总是使用十字路口。
在你的第一个实现中，一个菜单只能属于一个页面，所以它不是多对多的 – Andomar