决定何时扩展到子表

Question

我有一个实体表。例如目的，让我们称他们为Vehicles：Car，Boat，Motercycle，等。

我最想要的，将所有的实体在一个单一的Vehicles表，因为有很多相关的表（中VehicleRatings，VehicleComments，VehicleHistory，等）都将适用于任何实体，而不只是其中之一。

但是某些实体具有一些不与其他实体类型共享的单独属性。目前，一个实体只有 1 个额外属性，另一个实体则有 2 个额外属性。我希望以后可能会发现更多，但总体而言并不多。

我怎么知道什么时候最好为每个实体类型创建一个子表来存储这些单独的属性，而不是在父Vehicles表中添加一个额外的列？我有什么问题可以问自己来帮助确定这个答案吗？

我希望主要针对查询性能进行优化，其次是易于维护。

Answer 1

从逻辑 ERD 的角度来看，适当的设计显然是实体超类型/子类型模式。您正在努力解决的是如何从物理角度实现这一点。

像许多数据建模问题一样，没有硬性规定。您正在寻求妥协。您是否希望您的应用程序逻辑和查询（超类型/子类型）更加复杂，或者您是否希望您的应用程序逻辑可能无法正确执行您的约束以及合并表中的Car记录vehicle可能会获得非空值的风险anchor_weight列中的值？

在决定如何权衡这些替代方案时，您应该考虑的事项包括：

• 有多少子类型相关列？
• 将来定义新子类型的可能性有多大 - 或者需要新的子类型相关列？
• 如果为某些记录记录了不适当的数据（列值），情况会有多严重？
• 你在哲学上的立场是什么？（例如“空列是邪恶的”、“应用程序强制约束是邪恶的”、“1:1 关系是邪恶的”、“内连接是邪恶的”等）
• 我有多少查询只针对一种子类型？
• 我是否有任何编程环境限制使超类型/子类型物理模型更难使用（例如，大量使用 ORM 或像 Access 这样的简单工具）。

归根结底，您将根据对您最重要的事情做出实际决定。无论你做出什么决定都会有利有弊——但它们将是你的利弊。