一对多与多对多关联设计和优势

Question

我有一个非常基本的问题，出于某些奇怪的原因而使我感到困惑。

我有两个表，一个是“页面”表，另一个是“菜单”。 我想知道，使用另一个表进行映射有什么好处？ 以下是我正在考虑的两个实现：

我看到的唯一区别是搜索方式。 例如在第一个实现中：

a）如果我想要特定菜单的所有页面，我将查询特定菜单名称的所有page_id，并将它们与表Pages的ID结合在一起（这就是为什么我认为此实现更慢的原因） 。

b）如果我想要特定页面的所有菜单，我将搜索具有特定页面的page_id的所有菜单。

在第二种实现中，更典型，更直接（且具有更多的联接）。

我认为第二种实现是正确的，因为它更快（我想是因为它仅在作为索引的id之间查询，而不是像我在上文a中提到的那样在菜单名称中进行搜索）。

还是还有其他特殊原因？ 这两个设计在可以完成的事情上是相同的，还是第一个设计有其他限制，我总是应该选择第二个设计？

Answer 1

这两个选项不完全相同。 后者是在多对多设计中使用的正确选择。 使用联接表意味着您可以拥有许多页面（A，B，C）和许多菜单（1,2,3），并且可以将一组菜单与一组页面相关联（产生A1，A2，A3，B1 ，B2，B3，C1，C2，C3）。

第一种设计假定任何给定的菜单只能具有一个关联的页面。 菜单1只能与一页相关联（是A，B还是C？）。 要将同一个菜单与多个页面相关联，您需要在菜单表中为每个相关页面保留一行。

Answer 2

您的第一个实现是一对多，而不是一对多。 第二种实现是使用有效负载进行多对多操作（注意：它通常不需要id）。

多对多意味着您可以同时将n个项目映射到n个其他项目。 一对多意味着您只有一个项目映射到n个项目。

如果您需要很多，则只能在第二个实现中完成。 如果您需要一对多，则可以通过第一种方法完成。

Answer 3

页面和菜单具有多对多关系。 问题是，除了简单的关系事实之外，您是否需要跟踪有关该关系的任何信息？

例如，如果您发行杂志，则您可能拥有M2M的个人杂志关系-人们可以订阅多个杂志，而杂志可以具有多个订阅者。 但是，您要跟踪的是杂志和人物的相交信息-开始日期，到期日期等。使用相交表可以放置这些信息。

我从事这种工作已有一段时间了，我可以想到有很多实例，其中有一个M2M，在该M2M中，交集除了交集的存在以外就没有其他记录，因为该系统最初是被实现的。 但是，在几乎每种情况下，用户后来都要求进行增强，这需要有关该关系的其他信息。

所以我总是使用交叉路口。