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

时间:2015-09-25 10:59:31

标签: database entity-framework database-design

目前正在寻找一个新系统。与许多系统一样,它将需要存储文档并将它们链接到其他类型的项目。在这种情况下,Document对象可以属于Job,或者它可以属于Item(后者又属于作业)。

我们可以通过在Document上设置JobId和ItemId,并在必要时将其中一个留空,但这意味着处理代码中的条件逻辑很烦人。因此,两个链接表似乎更好。

但是,我们可能需要在将来某个时候将Documents链接到系统中的其他项目。例如,有CompanyUser个对象,我们可能希望针对这些对象记录Documents。可能会有更多。

这将导致链接表的扩散,虽然有效,但却很混乱,难以理解。

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

是否有任何设计原则可以让我们以更整洁,更灵活的方式将Document个对象与各种其他系统对象挂钩?

1 个答案:

答案 0 :(得分:2)

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

如果您有分区选项,则可以将不同的分区专用于不同的对象类型。

您还可以拥有多个表,一个用于作业文档,一个用于项目文档,并获得所有这些表的概述,以及UNION ALL将它们放在一起的视图。如果您在该结果集中需要唯一性,那么您可以使用UUID作为主键,或者向视图添加一个额外的列以表示从哪个表读取行。

相关问题