单独的id字段的单独列？

Question

假设我们有表A，B和C，然后我们希望表Z包含列TYPE，它告诉我们Z中的记录与A，B和C的哪个表相关联。

为列表A_ID，B_ID和C_ID添加单独的列是否更好，以便使用索引编制？

或者是否有一些理由为什么使用通用列TYPE_ID可能在性能方面更好？

Answer 1

使用type_id然后使用fk_id将不会很好，因为索引上的选择性是33％，这太高而无法使用。你总是会在fk_id上建立索引（链接到A，B，C） - 这可能需要在3个值之间打破平局（如果所有3种类型都使用了id）。

存储方面，索引永远不会存储空值，因此索引中存储的项目的绝对数量，无论是单个（fk_id）还是多个（a_id，b_id，c_id）都是相似的。

如果您从确切的fk_id（来自A，B，C）进入，那么按顺序使用（fk_id，type_id）上的唯一索引可以快速识别所需的记录。

看起来简单和简洁，这里有两列优于3。

Answer 2

这有时是架构代码的味道。

如果您考虑将其作为Z中的单个列，这是否意味着A，B，C中只有一个适用于Z？

在我决定之前，我真的说我必须更多地了解实体和使用模式。访问来自已知的A，B或C，还是从Z侧驱动的补充信息？如果它是从Z侧驱动的，你想要获得所有的A，B和C列，然后从应用程序中选择性地使用它们，或者只使用带有As的Zs和带有Bs的Zs - 即你通常知道子类型吗？另外，A，B和C有足够的列来表示Zs行的分离，如果它们各自为1-1（即你可以在Z中有列，只是为NULL）

为了完整性，另一种可以提供更多参照完整性的可能性（因为使用单个列，你不能成为三个表之一的FK）就是拥有表Z_A，Z_B，Z_C：

使用架构：

Z_A:
Z_ID REFERENCES (Z.ID)
A_ID REFERENCES (A.ID)

Z_B:
Z_ID REFERENCES (Z.ID)
B_ID REFERENCES (B.ID)

Z_C:
Z_ID REFERENCES (Z.ID)
C_ID REFERENCES (C.ID)

由于每个表中的所有ID都是唯一的，所以这一切都很好地限制了所有内容，除了在没有触发器的情况下没有任何声明可以阻止Z位于多个表中（您无法在SQL Server中的UNION ALL上对索引视图进行唯一约束）。

虽然它似乎会增加表的数量，但这些表通常可以包含在视图中。