标准化数据模型

标准化被定义为减少或消除数据集中冗余的过程。

它已成为关系数据库中数据建模的事实上的方法，很大程度上是由于这些系统最初设计时所围绕的底层资源限制：缓慢的磁盘和昂贵的 RAM。更少的数据冗余/重复意味着更有效地从磁盘读取数据并占用更少的空间。甚至一些像 Cassandra 这样的 NoSQL 数据库也鼓励采用非常标准化的方法来存储数据。

规范化通常需要创建一系列表，每个表可以有一组不同的字段，但给定表中的每条记录必须为其所有字段都有一个值 - 不多也不少。任何具有相当复杂的数据模型的应用程序最终都会将该数据分割到 10 个（如果不是 100 个甚至 1000 个）表中。在这些表中，数据通过“关系”链接在一起（即，表 1 中存储的记录包含到表 2 中记录的链接）。这些表、字段和关系就是所谓的“模式”。

标准化数据确实提供了一些好处：

• 重复数据删除：存储给定值一次并从多个位置引用它可以节省存储空间。
• 一致性：同样，更新仅存储在一个位置并从其他位置引用的值意味着更新可以应用一次并且不存在不一致。
• 数据完整性：规范化通常与数据库仅接受与正确字段（有时甚至是这些字段的数据类型）匹配的传入数据的能力相关。然而，我认为，虽然这是一项有益的功能，但它并不是直接源于规范化数据模型，而是源于底层实现。

然而，它也有一些缺点：

• 当数据进入系统时，必须将其划分到这些众多的表中，并且确保所有内容一起更新（即事务和关系完整性）可能会占用大量资源。
• 当应用程序请求多个数据点时，需要复杂（即慢速）JOIN 将多个表中的值拼凑在一起。
• 表中的所有记录必须相同，这使得存储不同结构的数据非常具有挑战性（几乎不可能）。引入与当前模型不同格式的数据需要新表，并且从一种结构更改为另一种结构可能需要大量停机时间。
• 阻抗不匹配：现代应用程序处理数据（即对象）的方式与在数据库中存储或检索数据的方式非常不同。

非规范化数据模型

另一方面，我们有非规范化，这是一种通常用于通过将类似数据分组在一起来提高性能的策略。历史上，数据被非规范化，通过避免跨表的复杂 JOIN 的需要来提高数据仓库中的报告性能。这带来了在多个模型中保持数据最新的额外挑战，但我们将在另一天再讨论脆弱的 ETL 管道。

在一些现代（即NoSQL）数据库中，非规范化被吹捧为解决关系数据库挑战的灵丹妙药。开发人员被告知要对一切进行非规范化，以便获得现代 Web 和移动应用程序所需的灵活性和性能。对于简单的数据模型，这很容易做到并且确实提供了显着的好处。然而，对于更复杂的数据模型，它实际上会使开发变得更加困难。

非规范化的好处是：

• 减少阻抗失配（对于简单应用）
• 模式从一个记录到另一个记录的轻松变化
• 通过一次性插入所有相关数据并删除跨表的 JOIN 进行检索，提高了性能。

然而，它也有权衡：

• 数据重复：相同的值在整个数据库中多次重复，增加了存储和处理要求。
• 数据不一致：数据重复意味着更新一个值需要在多个位置更改该值。由于这通常无法一次全部完成（或至少不能大规模完成），因此在进行更新时结果不一致
• 难以对复杂关系进行建模，实际上增加了企业应用程序的阻抗失配。复杂应用程序的多个组件都需要在不同时间以不同方式操作相同的数据。强迫他们在一个记录中合作（或竞争）实际上是不可能的。

讽刺的是，正如由于 RAM 和磁盘的限制而开发规范化数据模型一样，非规范化的建议也是从一些早期 NoSQL 技术的缺陷出发：不支持跨表的高效 JOIN，缺乏强一致性（即使在单个记录上）以允许记录之间的引用。

混合标准化/非标准化数据模型

Couchbase 的一个非常强大的方面是它支持多种混合规范化和非规范化数据类型。通过 JSON 可以轻松实现非规范化，而通过支持 JOIN 和强一致性可以轻松实现规范化……并且两者可以并存。

• 完全规范化的数据模型可以在多个订单中实现良好的重复数据删除。然而，在系统上线后为每个客户添加第二个（或第三个、第四个等）地址字段将是相当具有挑战性的。或者也许只为某些产品而不是其他产品添加评论。
• 另一方面，完全非规范化的数据模型使得一个客户拥有 1 个地址而另一个客户拥有 2 个地址变得非常容易。但是，在所有订单中更新产品描述可能会非常密集（即缓慢）并导致两个根据查询数据库的时间，对同一产品有不同的描述。它还会导致客户详细信息以及产品名称和描述的大量重复，从而需要更多的资源来存储、处理、备份等。

使用 Couchbase，可以在同一模式中同时拥有规范化和非规范化数据模型。这些数据在有意义的地方进行标准化：使用订单到产品和客户的参考来避免任何数据重复或不一致。它还在有意义的地方进行了非规范化：将所有客户数据保存在一个记录中，并允许不同的客户拥有不同的信息。它甚至是同一记录中两者的混合：虽然订单引用产品和客户，但它们还包含该订单中包含的任意项目列表。这很有道理。

只有当使用的数据库不仅能够支持强一致性，而且还能够具有强大的查询语言来表达数据记录之间的复杂关系时，这才有可能实现。