Sql 数据库设计模式：跨表的多对多关系？

我有以下表格：

部分和内容

我想把它们联系起来

我目前的做法如下表所示：

我将在其中存储

• 部分至部分
• 部分至内容
• 内容至部分
• 内容至内容

现在，虽然我可以通过添加一对字段来明确说明源是节还是内容，目标是节还是内容，但我想知道是否有更干净的方法来做到这一点。如果可能的话，只使用一个表来表示关系，这在我看来是最干净的。我还希望表格以某种方式与部分和内容表相关，这样我就可以避免手动添加约束，或在删除部分或内容时删除关系的触发器

---

像往常一样感谢您的输入 是的，有一种更干净的方法：

• 一个表跟踪节与节之间的关系，并将其作为外键约束强制执行
• 一个表跟踪从节到内容的关系，并将其作为外键约束强制执行
• 一个表跟踪从内容到部分的关系，并将其作为外键约束强制执行
• 一个表跟踪内容与内容之间的关系，并将其作为外键约束强制执行

这比一个带有重载ID的表要干净得多，而重载ID不能由外键约束强制执行。事实上，无论是数据建模，还是领域建模模式，都没有提到您所描述的模式，这应该是您的第一个警钟。第二个警报应该是引擎无法执行您设想的约束，您必须停留在触发器中

---

在一个表中建模四个不同的关系不会给模型带来优雅，它只会增加混淆。关系模型不是C++：它没有继承性，没有多态性，没有重载。试图在数据建模中强化面向对象的思维定势，导致许多优秀的开发人员陷入了无法维护的磁盘表触发器网格的泥潭，就像模糊地类似于“数据”的位一样。

我将如何设计它：

CREATE TABLE Pairables (
  PairableID INT IDENTITY PRIMARY KEY,
  ...other columns common to both Section and Content...
);

CREATE TABLE Sections (
  SectionID INT PRIMARY KEY,
  ...other columns specific to sections...
  FOREIGN KEY (SectionID) REFERENCES Pairables(PairableID)
);

CREATE TABLE Contents (
  ContentID INT PRIMARY KEY,
  ...other columns specific to contents...
  FOREIGN KEY (ContentID) REFERENCES Pairables(PairableID)
);

CREATE TABLE Pairs (
  PairID     INT NOT NULL,
  PairableId INT NOT NULL,
  IsSource   BIT NOT NULL,
  PRIMARY KEY (PairID, PairableID),
  FOREIGN KEY (PairableID) REFERENCES Pairables(PairableID)
);

您将在

对中为每对插入两行

现在搜索任何一种类型的可对实体都很容易，您可以在同一列中搜索源或目标，并且您仍然只需要一个多对多交叉表。
这或多或少是我的建议，只是我认为有一个遗漏。Pairs表不应该有两个不同的FK列，每个列都映射到PairableId的吗？@RMorrisey：也许，因为一个是源，另一个是目标。当配对是相互的“朋友”，没有被禁止的顺序时，我使用上面的模式。你是绝对正确的，但我的问题是，如果我曾经（上帝禁止）想要添加第三个表和第三种类型的关系数据（比如说“新闻”，也与站点中的一般部分和内容相关），我将不得不添加5个额外的表。。。9个表来关联三种类型的数据似乎很多，而且是指数级的。谢谢你的意见！您添加到模型中的每个表都将与其他所有现有表相关吗？在两个表之间有4个多对多关系这一事实已经是一个令人担忧的迹象，如果添加一个新的实体类型（一个新表）会使关系的数量呈指数级增加（与这些关系是在一个表中还是在两个表中或在9个表中强制执行无关），这让我严重怀疑数据模型设计的有效性。例如，如果你的模型实际上是2个（或3个或更多）类型的片段（内容、片段和现在的新闻），那么你真的在片段和片段之间有一个多对多关系表，片段和内容/片段/新闻之间的关系可以被建模为表继承模式之一。例如，你想做什么？章节和内容之间有什么区别？我们无法从这些关系中分辨出来。部分和内容（以及另一条评论中提到的“新闻”）可能都是更一般实体的实例……它们将是web内容的类型，例如，一个部分可以是一个类别，如“玩具”，并且一些“内容”取决于每个部分，因此“玩具”部分将有“儿童”部分，而“成人”部分。。。“玩偶”是一个依赖于“儿童”的内容，“扑克筹码”是一个依赖于“成人”的内容。。。这只是一个网站管理的层次结构