使用DBs,SQL:表“继承”分离决策

时间:2015-04-13 22:30:45

标签: sql database-design single-table-inheritance class-table-inheritance

假设我有一个数据库,其中一个实体(即表格)从另一个实体继承,例如:

  • Table 1,名为person(name,surname)
  • Table 2,名为car_owner

在这种情况下,car_owner person继承,即car-owner IS一个person。 我现在处于一个我必须决定是否应该这样做的地步:

  1. 创建表car_owner,即使除了person中的列之外没有其他列,但将来可能会更改=>执行此操作会导致car_owner =表格中包含(id,person_id)列,其中person_idFKperson
    1. 暂时只保留person表,只有(1) when/if有关car-owner的额外信息才会显示=>请注意,如果我这样做FK来自其他表格的car-owner实际上FKperson
    2. 我正在处理的表有不同的名称和语义,(1)(2)之间的选择不明确,因为需要额外的列在car_owner中可能永远不会弹出。

      从概念上讲,(1)似乎是正确的选择,但我想我所问的是,如果我有任何严重的问题,如果我转而使用 (2)

1 个答案:

答案 0 :(得分:2)

我建议选项1是更好的答案。虽然它为查询加入表创建了更多的工作,但是放置"可选"数据在自己的表中。如果需要更多类型的人(行人,车司机,汽车乘客),他们可以容纳更多的儿童桌。您始终可以使用视图使它们看起来像一个表。

对于数据库而言,我们说父母和孩子,而不是" inherets"。

回答有关选项2的问题/后果的部分 - 嗯,没有太严重。这是一个数据库,因此您可以随时重新安排事项,但如果重组表,则需要为重写查询和代码付出代价。为什么我不喜欢选项2是因为它可能导致额外的表不能重新使用人员部分。如果看起来该表是car_owners的话,我可能会为car_passengers创建一个全新的表,其中包含所有person列的重复项。 简而言之,任何一种方法都不会发生任何过于悲惨的事情,出于不同的原因它们都是优选的,缺点主要是不方便和潜在的未来混乱。