关于具有共同属性的SQL表

我在想一个问题，并且总是在我们的日常开发生活中发生。例如，我有一个table1 20列，table2 30列，表3 40列。但对于表1,2,3，他们有共同的10列。关于具有共同属性的SQL表

有几个例子可能会把它放在上下文中。

宠物商店大约有狗，猫，金鱼等，所有的宠物有一个名称，价格，得到的日期等，但每种宠物都有属性，其他类型的没有数据。

约车辆数据库具有关于汽车，卡车（货车），和摩托车的数据。他们都有车辆识别号码，注册号码和制造年份。但他们每个人都有自己的属性。

有关客户数据库有关于公司的那些客户，和个人是客户的数据。他们都有电话号码，但他们也有不同的属性。

那么什么是DB结构的合理设计。 A：用20,30,40列创建3个表格？ B：创建3表10,20,30列和另一个表共10列？如果我搜索一个记录，我需要加入共同表

因此我该如何分析这个性能题？不知道sql的工作原理，会为此做一些调查工作。任何人都可以共享有关设计和不同的性能

这种问题表面一遍又一遍在数据建模你的想法。它在ER建模中被称为“泛化/专业化”，在对象建模中被称为“超类/子类”。

对象建模器使用内置的对象模型的继承功能，很容易解决的问题。子类只是扩展超类。关系建模者面临一个问题。如何设计表格以模仿从继承中获得的好处？这是你提出的问题。

最简单的技术称为单表继承。有关所有子类的数据被分组到一个超类的单个表中。有一个列object_type将所有单个类型的对象组合在一起。没有任何对象可以属于多种类型。如果某列与其中一个子类无关，则该列在与该子类相关的行中将保留为NULL。

这种简单的解决方案非常适用于较小的和简单的情况。存在大量的NULL会增加存储开销的一小部分，并且检索开销稍微增加一点。如果布尔测试在可空列上完成，开发人员可能必须学习SQL三值逻辑。起初这可能会让人困惑，但人们已经习惯了。

还有另一种叫做类表继承的技巧。在这个设计中，除了所有专用子表的组合表之外，还有每个专用子类的独立表。当你需要关于特定类型对象的所有数据时，可以使用适当的专用表来加入常规表。在这个设计中有更少的NULL，但你做更多的加入。这种技术在更大和更复杂的情况下效果更好。

还有第三种技术称为共享主键。这种技术通常与类表继承一起使用。子类的专用表具有作为其主键的普通表中相应条目的主键的副本。此id列可以声明为主键和外键。

这需要在添加新对象时进行一些额外的编程，但它会使连接变得简单，轻松和快速。

超类和子类在现实世界中一直发生。让你的设计简单而健全。测试你的初始设计的性能。然后调整它，如果你需要。