一些例子可能会将其置于上下文中。
宠物商店有关于狗，猫，金鱼等的数据。所有宠物都有名称，价格，获得的日期等。但是每种宠物都具有另一种宠物没有的属性。
关于车辆的数据库包含有关汽车，卡车（卡车）和摩托车的数据。它们都有车辆识别号，注册号和一年制造。但他们每个人都有自己的属性。
有关客户的数据库包含有关客户公司和客户个人的数据。他们都有电话号码，但他们也有不同的属性。
那么DB结构的合理设计是什么。
答：用20,30,40列创建3个表？ B：用10,20,30列创建3个表，用10个常用列创建另一个表？如果我搜索一个记录，我需要加入公共表中的公共信息
那么我该如何分析这个性能问题呢？不知道sql的工作原理，会为此做一些调查工作。 任何人都可以分享您对设计和不同性能的看法
答案 0 :(得分：3)
这种问题在数据建模中反复出现。它在ER建模中称为“泛化/专业化”，在对象建模中称为“超类/子类”。
对象建模器使用对象模型中内置的继承功能来轻松解决问题。子类只是扩展了超类。 关系建模者面临着一个问题。如何设计表格以模仿从继承中获得的好处？这就是你提出的问题。
最简单的技术称为单表继承。有关所有子类的数据被分组为超类的单个表。有一个列object_type，它将单个类型的所有对象组合在一起。没有对象可以属于多种类型。如果列与其中一个子类无关，则它将在与该子类相关的行中保留为NULL。
这种简单的解决方案适用于较小和较简单的情况。存在大量的NULL会给存储开销增加一点点，并且会有一点点来检索开销。如果在可空列上进行布尔测试，开发人员可能必须学习SQL三值逻辑。起初这可能令人困惑，但人们会习惯它。
还有另一种技术，称为类表继承。在这种设计中，每个专用子类都有单独的表，以及所有子类的组合表。如果需要有关特定类型对象的所有数据，可以使用适当的专用表连接常规表。此设计中的NULL较少，但您可以进行更多的连接。这种技术在更大，更复杂的情况下效果更好。
还有第三种技术称为共享主键。此技术通常与类表继承一起使用。子类的专用表具有通用表中相应条目的主键的副本作为其主键。可以将此id列声明为主键和外键。
这需要在添加新对象时进行一些额外的编程，但它使连接变得简单，容易和快速。
超级类和子类一直在现实世界中发生。让您的设计简单而有声。测试您的初始设计的性能。然后根据需要进行调整。