我有一个产品表中调用products 它有3个字段（名称，型号（PK），和CLASS_NAME）。该类对应于一个表。 所以这里有一个例子：理解类表继承
产品表：
model | name | class_Name
z123 | Abcd | AMPS
AMPS表：
model | attribute_1 | attribute_2
z123 | blah blah | blah blah
问：
我是否应该保存的PK表（模型）和其相应的类名称，然后在我的产品表中使用类ID？拥有一个可以容纳所有模型及其类的表格会更有效率吗？
这看起来像一个“子类”（aka。“category”）层次结构。如果你有和总是只有AMPS，并没有其他“子级”，那么你可以考虑合并它与Product。否则，它看起来不错。
BTW，有3 ways实现在关系数据库中的类层次，各有长处和短处。将所有类保存在一个表中是其中的一个，但可能难以维护，并且对于某些类型的参照完整性可能存在问题。你已经在使用（“每类表”）也许应该是您的默认选择，除非有另有一个令人信服的理由，该模型...
是的，每款产品都会有特定的类别。我知道实现类层次结构的三种方法，“每个表的类”看起来像是解决我所遇到的特定问题的最合理的方法。谢谢 – 2012-02-23 02:24:00
有已经是一个公认的答案，但我加入的好处如下的其他人在运行此Q.请注意，此解决方案与在主表中指示子类明显不同。在我看来，它既简单又灵活。
你的情况看起来像被称为“泛化专业化”（根规格的简称）设计模式的一个实例。 gen-spec模式对于面向对象的程序员来说很熟悉。在教授关于继承和子类的教程时将会介绍它。
实现gen-spec模式的SQL表的设计可能有点棘手。数据库设计教程常常掩盖了这个主题。但它在实践中一次又一次地出现。
如果你搜索“泛化专业化关系建模”网页，你会发现一些有用的文章，教你如何做到这一点。在这个论坛中，你也会被指出几次这个话题。
这些文章通常告诉你如何设计一个表来捕获所有的通用数据和一个专门的表将包含所有特定于该子类中的数据的每个子类。有趣的部分涉及子类表的主键。您不会使用DBMS的自动编号功能来填充子类主键。相反，您将编写应用程序以将通用表中获得的主键值传播到适当的子类表中。
这在广义数据和专用数据之间建立了双向关联。每个专门的子类的简单视图将一起收集广义和专门的数据。一旦你掌握了它，它很容易，它表现相当好。
添加了SQL标签，以便实际获得答案。 – 2012-02-22 23:50:38
@DhaivatPandya谢谢！ – 2012-02-22 23:51:45
我没有看到你在做什么错，我怀疑添加表会有所帮助。但是，您应该考虑询问更具体的问题。你的目标是什么？如果你担心效率，你想优化什么？ – 2012-02-23 00:10:08