DB表的泛化与专业化

Question

当我想设计模拟有限父子关系的数据库表时，例如，计算机作为父，以及作为子的内部组件;或者是一个简单的组织层次结构，我常常被迫使用哪种方法 -

1. 一种'专用表'方法，我在其中为每个可能的实体创建一个表。在计算机组件示例中，我将有一个Computer表和一个Component表，在Component表中将ComputerID作为FK引用回Computer.ComputerID。 或
2. 一种通用表方法，其中我有一个名为Component的表表，ComponentID为PK，而ParentComponentID为FK，引用其父组件ID。

Answer 1

我在大多数情况下选择选项1超过2的原因是因为将父行拉出数据库更容易。否则，您必须编写sql语句，以便从表中获取具有子行的行，但仅限于那些行。它很快就会混乱。

如果您使用的是任何常见的关系数据库，请按照设计使用的方式使用它们。

Answer 2

如果我知道我需要能够扩展模型以支持层次结构中的新级别，我更喜欢通用表。

广义表的缺点是失去了强类型，我通常通过添加'类型'表（即通用'组件'表的'ComponentType'）来解决这个问题。

这允许可以扩展的模型，并且仍然提供层次结构中每个组件的强类型。

编辑： Marcus提出了计算机与组件相同的问题。我应该澄清，广义表方法应该用于类似的对象。

Answer 3

当您尝试创建实际上不是真实的概括但看起来优雅时，关系设计会有很大的危险。如果你有一个带有类型字段的通用表，那么会引入一种必须在你的代码中解决的间接形式，这会损害性能和代码的清晰度。

另一方面，这种间接可以有其用途，并且出于某些目的，我使用它非常多。你要问的问题是计算机和组件是否真的是同一个方面，或者你是否只是将它们捏在一起因为听起来不错。

Answer 4

根据我的经验，广义表格方法很诱人，因为它会给你更多的权力，但从长远来看，你会发现遵循和维护是很复杂的。

Answer 5

使用两者后，新程序员肯定更容易掌握前者。在大多数简单的情况下处理它也更简单。

后者派上用场，是事物等级可能发生变化的地方;或者对象更改其层次结构顺序或层次结构本身更改。当层次结构很复杂时，它也很有用，因为您不必将其建模为数据库中的表。