sql - 您应该使用单表继承还是在一个 View 中联合使用多个表？

Question

假设您有一个注释表。备注可以是关于特定帐户、订单行或订单的。

• 关于该帐户的注释不适用于任何特定订单行或订单。
• 关于订单行的注释也适用于父订单和附加到订单的帐户。
• 订单上的注释也适用于附加帐户，但不适用于订单行。

备注表

[Id]          [int] IDENTITY(1,1) NOT NULL
[NoteTypeId]  [smallint] NOT NULL
[AccountId]   [int] NULL
[OrderId]     [int] NULL
[OrderLineId] [int] NULL,
[Note]        [varchar](300) NOT NULL

想法是，如果我查看客户，我可以看到所有以某种方式相关的注释。最初我为上面的每一个创建了一个注释表并在一个 View 中联合它们。这里的问题来自编辑/删除记录。可以在特定项目上或在帐户或订单的通用注释 View 中编辑/删除注释。这种方法使这变得更加困难。

然后我切换到 Single Table Inheritance图案。我的备注表具有可为空的 AccountId、OrderId 和 OrderLineId 值。我还添加了 NoteTypeId 以明确标识记录。更容易管理更新/删除方案。

我对这种方法仍有一些问题和疑问。

• 完整性 - 虽然可以在 SQL 和/或代码中设置复杂的约束，但大多数 DBA 不喜欢 STI 方法。
• 一堆空值的想法存在争议(尽管我相信 SQL 2008 中的性能已根据空值的存储得到改进)
• >RDBMS 中的表不必在代码中表示对象。表格中的规范化并不表示表格必须是唯一对象。我相信前两句话是真的，你说呢？

这里讨论了一些。 Is an overuse of nullable columns in a database a "code smell"?我不得不说我同意 Ian 的观点，但我也希望看到一些相反的观点。

Answer 1

Although complex constraints can be set in SQL and/or in code, most DBAs would not like the STI approach.

因为您需要额外的逻辑(CHECK 约束或触发器)来实现注释仅引用其中一个实体(帐户、订单、订单行)的业务规则。

在每个实体和注释表之间实现一个多对多的表更具可扩展性。

• 不需要 ALTER TABLE 语句来添加另一个可为 null 的外键(有列限制，并不是大多数人都可能达到)
• 单个笔记记录可以与多个实体相关联
• 添加新实体和多对多表对现有记录没有影响