There are at least three approaches to representing class inheritance in a database
Single Table Inheritance: All attributes in the whole inheritance tree are stored in a single table and there is a dedicated column which describes the type of the row. This means that there will be many unused columns, so this approach makes sense only when subclasses share most of the attributes.
Class Table Inheritance: Every class in the tree is persisted in a separate database table which stores only attributes specific to the class. This means that in order to fetch an object your have to join across tables representing ancestors in the inheritance tree.
Concrete Table Inheritance: There is a separate database table for each concrete class, but all attributes needed by a given class are stored, including the inherited ones. This means you don't have to join, but on the other hand you cannot upcast (eg. when you query for products you won't see any shoes).
Each of these approaches has pros and cons, it's a trade-off that you have to make.
On the other hand using inheritance to represent the product type means that you'll have to modify both the code and the database schema every time you introduce a new product type. If the types are going to change a lot and there is not much logic associated with each type, then it might be better to use a single (producId, key, value) table of product properties. It's not a beautiful database design, but it's going to be much more practical in such case.
然而，我建议使用单表继承（正如 Adam 提到的）并避开 EAV。如果您的 RDBMS 支持 XML 类型并且您担心所有可为 NULL 的字段的存储，请将所有可选数据放入单个 XML 列中。然后，架构验证将确保您不会尝试用一双鞋等来存储处理器类型。
然后，为每个产品类型添加额外的字段就像更新该特定产品的架构一样简单。
Your object design is good.
However, I suggest using single table inheritance (as mentioned by Adam) and steer clear away from EAV. If your RDBMS supports XML types and you're worried about storage of all the NULLable fields, put all the optional data in a single XML column. Schema validation will then ensure that you don't try to store a processor type with a pair of shoes, etc.
Adding extra fields per product type is then as simple as updating the schema for that particular product.
Your design is the correct standard for today. It's called Normalization, breaking up objects into smaller object tables. That's the whole purpose of a relational database. I would stay on the path you are on
发布评论
评论（3）
数据库中至少有三种表示类继承
这些方法各有利弊，您必须做出权衡。
另一方面，使用继承来表示产品类型意味着每次引入新的产品类型时都必须修改代码和数据库架构。如果类型将发生很大变化，并且与每种类型相关的逻辑不多，那么最好使用单个产品属性表（productId、key、value）。这不是一个漂亮的数据库设计，但在这种情况下它会更加实用。
There are at least three approaches to representing class inheritance in a database
Each of these approaches has pros and cons, it's a trade-off that you have to make.
On the other hand using inheritance to represent the product type means that you'll have to modify both the code and the database schema every time you introduce a new product type. If the types are going to change a lot and there is not much logic associated with each type, then it might be better to use a single (producId, key, value) table of product properties. It's not a beautiful database design, but it's going to be much more practical in such case.
你的对象设计很好。
然而，我建议使用单表继承（正如 Adam 提到的）并避开 EAV。如果您的 RDBMS 支持 XML 类型并且您担心所有可为 NULL 的字段的存储，请将所有可选数据放入单个 XML 列中。然后，架构验证将确保您不会尝试用一双鞋等来存储处理器类型。
然后，为每个产品类型添加额外的字段就像更新该特定产品的架构一样简单。
Your object design is good.
However, I suggest using single table inheritance (as mentioned by Adam) and steer clear away from EAV. If your RDBMS supports XML types and you're worried about storage of all the NULLable fields, put all the optional data in a single XML column. Schema validation will then ensure that you don't try to store a processor type with a pair of shoes, etc.
Adding extra fields per product type is then as simple as updating the schema for that particular product.
您的设计是当今的正确标准。这称为标准化，将对象分解为更小的对象表。这就是关系数据库的全部目的。我会留在你所走的路上
Your design is the correct standard for today. It's called Normalization, breaking up objects into smaller object tables. That's the whole purpose of a relational database. I would stay on the path you are on