DB表的泛化与专业化

时间:2009-01-23 15:43:34

标签: database

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

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

5 个答案:

答案 0 :(得分:4)

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

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

答案 1 :(得分:3)

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

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

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

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

答案 2 :(得分:3)

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

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

答案 3 :(得分:2)

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

答案 4 :(得分:1)

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

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