我们有一个J2EE内容管理和电子商务系统，在这个系统中 - 为了一个简单的例子 - 假设我们有100个对象。所有这些对象都扩展了相同的基类，并且它们共享许多相同的字段。
让我们以两个对象为例：一个将在网站上发布的新闻项目，以及一个将在网站上销售的产品。这两者都有共同的属性：
当然，他们有一些不同的属性：
所以（最后）这是我的问题。假设我们的系统中有100个对象，它们都遵循这种模式。它们有许多重叠的字段，以及一些独特的字段。就关系数据库而言，我们会更好：
选项一：减少表格，通用表格
选项二：更多表格，重复的常用字段
对于完全披露 - 我是开发人员而不是DBA，因此我更喜欢选项。但是还有另一个团队成员更喜欢选项二，我认为他提出了有效的观点。
选项一：优点和缺点
选项二：优点和缺点
我的两分钱
对我来说，我更喜欢第一种选择的优雅 - 但也许这就是我试图在关系数据库上强制面向对象的模式。如果所有事情都是平等的，我会选择一个，除非数据库专家告诉我，当我们在系统中有数百万个对象时，选项一会产生性能问题。
为冗长的问题道歉。我对DB lingo不太满意，所以如果我更好地理解像规范化这样的术语，我可能会更简洁地总结一下。我试图搜索关于这个主题的答案，虽然我发现很多很接近（我怀疑这是一个常见的数据库问题）但我找不到任何能回答我所有问题的答案。我通过this article了解了规范化：
但我并不完全明白。一方面，它说你应该删除任何冗余。但另一方面，它说每个属性应该只定义一个对象。
谢谢，
约翰
答案 0 :(得分：2)
你应该阅读Martin Fowler撰写的Patterns of Enterprise Application Architecture。他为您描述的场景写了几个选项：
Single Table Inheritance：所有对象子类型的一个表。存储所有属性，将它们设置为NULL，使其不适用于行的对象子类型。
Class Table Inheritance：一个表格用于所有子类型共有的列，然后是每个子类型的一个表格，用于存储特定于子类型的列。
Concrete Table Inheritance：每个子类型一个表，存储所有子类型共有的特定于子类型的列和列。
Serialized LOB：所有对象子类型的一个表。将常用属性存储为常规列，但将可选或特定于子类的列组合为存储XML或JSON或您想要的任何格式的BLOB中的字段。
这些设计中的每一个都有利有弊，因此请根据您访问数据的最常用方式选择解决方案。
但是，请注意我使用上面的子类型一词。只有当不同的对象类型是公共基类的子类型时，我才会使用这些设计。我假设News item和Product实际上并不共享逻辑基类（Object除外）;它们不是普通超类的子类型。
因此，为了OO设计，我会选择Concrete Table Inheritance。这避免了这些子类型之间的任何不适当的耦合。这两个表有共同的列，但它们基本上等于簿记，而不是与类的功能有关，因此与表有关。