mysql - 数据库规范化——我想？

Question

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

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

• IDs: id, client ID, parent ID (long)
• 标志:已删除、已存档、不活动( bool 值)
• 日期:创建、修改、删除(日期时间)
• 内容:名称、描述

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

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

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

选项一:更少的表，通用表

• table_id: id, client ID, parent ID (long)(id为主键，所有对象的一个​​GUID)
• table_flag: id, deleted, archived, inactive (boolean)
• table_date: id, created, modified, deleted (datetime)
• table_content: id, name, description
• table_news:id，作者，发布日期
• table_product: id, price, tax

选项二:更多表格，重复常用字段

• table_news: id, client ID, parent ID, deleted, archived, inactive, name, description, author, posting date
• table_product:id、client ID、parent ID、deleted、archived、inactive、name、description、price、tax

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

选项一:优点和缺点

• 优点:将常用字段封装到常用表中。
• Pro:需要更改公共(public)字段？在一个地方更改它。
• 优点:仅在需要时创建新字段/表格。
• 优点:更容易动态创建查询，减少重复代码
• 缺点:更多的连接来创建对象(不确定数据库对此有何影响)
• 缺点:存储对象的查询更复杂(不确定数据库对此有何影响)
• 缺点:公用表会随着时间的推移变得越来越庞大

选项二:优点和缺点

• Pro:也许将所有对象的负载分散到表中会更好？
• 优点:可以在客户端 ID 上索引新闻表，并在父 ID 上索引产品表。
• 优点:对人眼来说更具可读性:很容易在一张表中查看对象的所有字段。

我的两分钱

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

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

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

谢谢，

约翰

Answer 1

你应该阅读 Patterns of Enterprise Application Architecture马丁·福勒。他为您描述的场景写了几个选项:

• Single Table Inheritance :所有对象子类型的一个表。存储所有属性，在它们不适用于行的对象子类型时将它们设置为 NULL。

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

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

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

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

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

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