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