Database 在数据库设计中是否有一种模式可以避免不断增加链接表？

目前正在确定新系统的范围。与许多系统一样，它需要存储文档并将它们链接到其他类型的项目。在这种情况下，

文档

对象可以属于

作业

，也可以属于

项

（而该项又属于作业）

我们可以通过在

文档

上设置一个JobId和一个ItemId，并在必要时将其中一个保留为空，但这将意味着处理代码中存在恼人的条件逻辑。因此，两个链接表似乎是一个更好的主意

但是，在将来的某个时候，我们可能需要将

文档

链接到系统中的其他项目。例如，有

公司

和

用户

对象，我们可能希望根据这些对象记录

文档

。可能还有更多

这将导致链接表的激增，这些链接表虽然有效，但混乱且难以遵循

此解决方案位于SQL Server中，将通过实体框架在代码中处理

---

是否有任何设计原则允许我们以更整洁、更灵活的方式将

文档

对象与所需的各种其他系统对象连接起来？

您可以存储两个值：id和文档所附着对象的类型。它不允许使用外键，但与许多应用程序开发框架兼容

如果您有分区选项，那么您可以将不同的分区专用于不同的对象类型

---

您还可以有多个表，一个用于作业文档，一个用于项目文档，并通过将所有表合并在一起的视图对所有表进行概述。如果您需要该结果集中的唯一性，那么您可以使用UUID作为主键，或者在视图中添加一个额外的列来表示从哪个表中读取该行。

谢谢您的建议。我们确实考虑过在没有密钥的情况下使用id类型的解决方案，但我认为这与实体框架不兼容，它需要这样。我忽略了这个重要的信息，现在我已经添加了它。让我想到的是Rails，在它中，您可以创建一个带有documentable_id和documentable_类型的文档表，它对ActiveRecord很有效，但对于数据库外键却不是很好。