了解类表继承

Question

我有一个产品表，products 它具有3个字段（名称，模型（PK）和类名）。该类对应于一个表。所以这是一个例子：

产品表：

model | name | class_Name
z123  | Abcd | AMPS

AMPS表：

model | attribute_1 | attribute_2
z123  | blah blah   | blah blah

题：

我是否应该有一个包含PK（模型）及其相应类名的表，然后在我的产品表中使用该类ID？有一个表来容纳所有模型及其类的表会更有效吗？

Answer 1

已经有一个公认的答案，但为了其他遇到此问题的人的利益，我添加了以下内容。请注意，此解决方案与在主表中指示子类明显不同。在我看来，它既简单又灵活。

您的案例看起来像是称为“泛化专业化”（简称 Gen-Spec）的设计模式的一个实例。面向对象的程序员熟悉 gen-spec 模式。在教授继承和子类时，它在教程中有所介绍。

实现 gen-spec 模式的 SQL 表的设计可能有点棘手。数据库设计教程经常掩盖这个话题。但它在实践中一次又一次地出现。

如果您在网上搜索“泛化专业化关系建模”，您会发现几篇有用的文章，教您如何做到这一点。您还会在此论坛中多次提到此主题。

这些文章通常会向您展示如何设计一个表来捕获所有通用数据，并为每个子类设计一个专门的表，该表将包含特定于该子类的所有数据。有趣的部分涉及子类表的主键。您不会使用 DBMS 的自动编号功能来填充子类主键。相反，您将对应用程序进行编程，以将针对通用表获得的主键值传播到适当的子类表。

这在广义数据和专门数据之间创建了一种双向关联。每个专用子类的简单视图将收集通用数据和专用数据。一旦你掌握了它，这很容易，而且性能相当好。

Answer 2

这看起来像一个“子类”（又名“类别”）层次结构。如果您拥有并且将永远只有AMPS且没有其他“子类”，那么您可以考虑将其与合并Product。否则，看起来不错。

顺便说一句，在关系数据库中有3种方法来实现类层次结构，每种方法各有优缺点。将所有类保存在一个表中是其中之一，但是可能很难维护，并且可能对某些类型的引用完整性造成问题。您已经使用的模型（“每个表的类”）应该是您的默认选择，除非有其他令人信服的理由...