Database design 如何确定数据库规范化的程度？

在创建数据库结构时，应该遵循哪些好的指导原则或确定数据库应规范化到何种程度的好方法？您是否应该创建一个未规范化的数据库，并随着项目的进展将其拆分？您是否应该创建一个完全规范化的数据库，并根据性能需要合并表？

我认为，从一个未规范化的数据库开始，并随着您的进步向规范化的方向发展通常是最容易开始的。至于要正常化到什么程度的问题，我的哲学是正常化，直到它开始受到伤害。这听起来可能有点轻率，但一般来说，这是一个很好的衡量方法。

杰夫在他的博客上对他的哲学有一个很好的概述：。最重要的是：不要过度规范化。但我认为更重要的一点是，这可能并不重要。除非你正在运行下一个Google，否则在你的应用程序增长之前，你可能不会注意到有多大的不同。

我觉得数据库规范化是一种艺术形式

您不希望过度规范化数据库，因为您将有太多的表，这将导致您对即使是简单对象的查询所花费的时间也比应该的要长

我遵循的一个很好的经验法则是对重复的相同信息进行规范化

例如，如果您正在创建一个联系人管理应用程序，将地址（街道、城市、州、邮政编码等）作为自己的表是有意义的

但是，如果您只有两种类型的联系人，业务联系人或个人联系人，如果您知道您只有两种类型的联系人，是否需要联系人类型表？对我来说不

我首先要弄清楚您需要的数据类型。使用建模程序来帮助您，如Visio。您不希望从一个非规范化的数据库开始，因为您最终将规范化。首先将对象放在逻辑分组中，当您看到重复的数据时，将该数据放入一个新表中。我会一直保持这个过程，直到你觉得你已经设计好了数据库

---

让测试告诉您是否需要合并表。写得好的查询可以覆盖任何过度规范化。

您希望开始设计一个规范化数据库，直到第三个标准形式。当您开发业务逻辑层时，您可能会决定必须稍微去规范化一点，但决不能，决不能低于第三种形式。始终保持第一和第二表格的一致性。您希望反规范化是为了代码的简单性，而不是为了性能。为此使用索引和存储过程：）

不“随用随规范化”的原因是，每次修改数据库设计时，都必须修改已经编写的代码

这里有几篇好文章：

---

@GrizzlyGuru一位智者曾经告诉我“正常化直到受伤，非正常化直到成功”

我还没有失望：）

---

我不同意从非规范化的形式开始，但是根据我的经验，使应用程序能够处理规范化程度较低的数据库比处理规范化程度较高的数据库更容易。它还可能导致这样的情况，即它“工作”得“足够好”，所以你永远都没有时间对它进行规范化（直到“太晚了！”）

通常，如果你尽可能地规范化其他软件，你就会成功

---

例如，当使用对象关系映射技术时，您将拥有一组丰富的语义，用于各种多对一和多对多关系。在引擎盖下，它将为连接表提供有效的2个主键。虽然相对罕见，但真正的规范化通常会提供与3个或更多主键的关系。在这种情况下，我更喜欢使用O/R并滚动我自己的代码以避免各种数据库异常。

拥有一个规范化的数据库将为您提供最大的灵活性和最简单的维护。我总是从一个规范化的数据库开始，然后只有在存在需要解决的实际问题时才取消规范化

---

我认为这与代码性能类似，即编写可维护、灵活的代码，并在您知道存在性能问题时为性能做出妥协

我同意通常最好从规范化的DB开始，然后反规范化以解决非常具体的问题，但我可能从第三个规范化开始，而不是从第三个规范化开始。

规范化意味着消除冗余数据。换句话说，非规范化或非规范化数据库是指相同信息将在多个不同位置重复的数据库。这意味着您必须编写更复杂的update语句，以确保在任何地方都更新相同的数据，否则会得到不一致的数据，这反过来意味着查询的输出是不可靠的

这是一个相当大的问题，所以我想说，非规范化是有害的，而不是相反

在某些情况下，您可能会故意决定对数据库的特定部分进行非规范化，如果您认为这样做的好处大于更新数据的额外工作和数据损坏的风险。例如，对于数据仓库，出于性能原因对数据进行聚合，如果数据在初始条目之后经常不更新，则会降低不一致的风险

---

但总体而言，我们对性能的非规范化感到厌倦。例如，非规范化联接的性能优势通常可以通过使用物化视图（也称为索引视图）来实现，该视图与查询非规范化表一样快，但仍然可以保护数据的一致性。

请尝试使用常识

也有人说——我必须同意它们——如果你发现自己在大多数的查询中加入了6个（神奇的数字）表——不包括与报告有关的表，那么你可能会考虑去变性化。

事实是，这取决于很多因素，包括：

• 代码（手工编码或工具驱动（如ETL包））
• 主要应用(