数据库规范化 - 我认为？

Question

我们有一个 J2EE 内容管理和电子商务系统，在这个系统中——举个简单的例子——假设我们有 100 个对象。所有这些对象都扩展同一个基类，并且都共享许多相同的字段。

我们以两个对象为例：将发布在网站上的新闻项目和将在网站上销售的产品。这两者具有共同的属性：

• ID：id、客户端 ID、父 ID（长）
• 标志：已删除、已归档、非活动（布尔值）
• 日期：创建、修改、删除（日期时间）
• 内容：名称、描述

当然它们有一些不同的属性：

• 新闻项目：作者、发布日期
• 产品：价格、税收

所以（最后）这是我的问题。假设我们的系统中有 100 个对象，它们都遵循这种模式。它们有许多重叠的领域，以及一些独特的领域。就关系数据库而言，我们是否会更好：

选项一：少表，普通表

• table_id：id、客户端ID、父ID（长）（id为主键，所有对象的GUID）
• table_flag：id、已删除、已归档、非活动（布尔值）
• table_date：id，创建，修改，删除（日期时间）
• table_content：id、名称、描述
• table_news：id、作者、发布日期
• table_product：id、价格、税金

选项二：更多表，重复公共字段

• table_news：id、客户 ID、父 ID、已删除、已归档、非活动、名称、描述、作者、发布日期
• table_product：id、客户 ID、父 ID、已删除、已归档、非活动、名称、描述、价格、税费

为了全面披露——我是一名开发人员而不是 DBA，因此我更喜欢选项一。但是还有另一个团队成员更喜欢选项二，我认为他的观点是正确的。

选项一：优点和缺点

• 专业版：将常用字段封装到常用表中。
• 专业人士：需要更改公共字段？在一处进行更改。
• 专业版：仅在需要时创建新字段/表。
• 专业版：更容易动态创建查询，重复代码更少
• 缺点：更多连接以创建对象（不确定数据库对此有何影响）
• 缺点：存储对象的查询更复杂（不确定数据库对此有何影响）
• 缺点：随着时间的推移，常用表会变得很大

选项二：优点和缺点

• Pro：也许最好将所有对象的负载分布在表中？
• 专业版：可以在客户端 ID 上索引新闻表，并在父 ID 上索引产品表。
• 专业版：人眼可读性更强：在一个表中轻松查看对象的所有字段。

我的两分钱

对我来说，我更喜欢第一个选项的优雅——但也许那是我试图在关系数据库上强制使用面向对象的模式。如果一切都一样，我会选择选项一，除非数据库专家告诉我，当系统中有数百万个对象时，选项一会产生性能问题。

为冗长的问题道歉。我对 DB 术语不太熟悉，所以如果我更好地理解规范化等术语，我可能会更简洁地总结这一点。我试图寻找关于这个主题的答案，虽然我发现很多答案都很接近（我怀疑这是一个常见的数据库问题），但我找不到任何能回答我所有问题的答案。我通读了this article 的规范化：

但我并没有完全理解它。一方面，它是说你应该删除任何冗余。但另一方面，它是说每个属性应该只定义一个对象。

谢谢，

约翰

Answer 1

您应该阅读 Martin Fowler 的 Patterns of Enterprise Application Architecture。他为您描述的场景写了几个选项：

• Single Table Inheritance：一张表用于所有对象子类型。存储所有属性，如果它们不适用于行的对象子类型，则将它们设置为 NULL。

• Class Table Inheritance：一张表用于所有子类型共有的列，然后每个子类型一张表用于存储特定于子类型的列。

• Concrete Table Inheritance：每个子类型一个表，存储子类型特定的列和所有子类型共有的列。

• Serialized LOB：一张表用于所有对象子类型。将通用属性存储为常规列，但将可选或特定于子类型的列组合为存储 XML 或 JSON 或任何您想要的格式的 BLOB 中的字段。

这些设计中的每一种都有利有弊，因此请根据您访问数据的最常用方式来选择解决方案。

但是，请注意我在上面使用了 subtype 这个词。只有当不同的对象类型是公共基类的子类型时，我才会使用这些设计。我假设News item 和Product 实际上并不共享逻辑基类（除了Object）；它们不是公共超类的子类型。

所以为了OO设计，我会选择Concrete Table Inheritance。这避免了这些子类型之间的任何不适当的耦合。这两个表有一些共同的列，但它们基本上相当于簿记，与类的功能以及表的功能无关。