我有一个名为products
它的产品表，它有 3 个字段（名称、型号（PK）和类名）。类对应一个表。所以这里有一个例子：
产品表：
model | name | class_Name
z123 | Abcd | AMPS
安培表：
model | attribute_1 | attribute_2
z123 | blah blah | blah blah
问题：
我是否应该有一个包含 PK（模型）及其相应类名的表，然后在我的产品表中使用类 ID？拥有一个包含所有模型及其类的表会更有效吗？
已经有一个公认的答案，但我添加以下内容是为了让其他遇到此问题的人受益。请注意，此解决方案与在主表中指示子类明显不同。在我看来，它既简单又灵活。
您的案例看起来像是被称为“泛化专业化”（简称 Gen-Spec）的设计模式的一个实例。面向对象的程序员很熟悉 gen-spec 模式。在教授继承和子类时，它会在教程中介绍。
实现 gen-spec 模式的 SQL 表的设计可能有点棘手。数据库设计教程经常掩盖这个主题。但它在实践中一次又一次地出现。
如果你在网上搜索“泛化专业化关系建模”，你会发现几篇有用的文章教你如何做到这一点。您还将在此论坛中多次指出该主题。
这些文章通常向您展示如何设计一个表来捕获所有通用数据，并为每个子类设计一个专门的表，其中将包含该子类特定的所有数据。有趣的部分涉及子类表的主键。您不会使用 DBMS 的自动编号功能来填充子类主键。相反，您将对应用程序进行编程，以将从通用表获得的主键值传播到适当的子类表。
这在通用数据和专用数据之间创建了双向关联。每个专用子类的简单视图将一起收集通用数据和专用数据。一旦掌握了它就很容易，并且性能相当不错。
这看起来像一个“子类”（又名“类别”）层次结构。如果您有并且永远只有AMPS并且没有其他“子类”，那么您可以考虑将其与Product. 否则，它看起来不错。
顺便说一句，有3 种方法可以在关系数据库中实现类层次结构，每种方法都有优点和缺点。将所有类保存在一个表中就是其中之一，但可能难以维护，并且对于某些类型的引用完整性可能会出现问题。您已经使用的模型（“每个表的类”）可能应该是您的默认选择，除非有令人信服的理由……