数据库规范化已死吗？[关闭]

我从小就读过-我们学会了在应用程序的业务层之前设计数据库架构（或使用OOAD进行其他所有操作）。我在设计模式（IMHO :)方面一直做得很好，并且进行规范化只是为了删除不必要的冗余，而没有在影响速度的地方进行标准化，即，如果联接对性能造成了影响，则冗余就留在了原处。但大多数情况并非如此。

随着一些ORM框架（如Ruby的ActiveRecord或ActiveJDBC）的出现（还有我不记得的其他几个，但是我敢肯定有很多），似乎他们更喜欢为每个表使用代理键，即使有些表具有主键，例如'电子邮件'-彻底破坏2NF。好的，我了解不多，但是当其中一些ORM（或程序员）不承认1-1或1-0 | 1（即1到0或1）时，我（几乎）感到不安。他们规定，最好将所有内容都放在一张大桌子上，而不管它是否有大量的nulls “当今系统可以处理它”，这是我经常听到的评论。

我同意内存限制确实与规范化有直接关系（还有其他好处：），但是在 当今廉价的内存和四核计算机的时代，DB规范化的概念是否留给文本？作为DBA，您是否仍在对3NF（如果不是BCNF ：）进行标准化？有关系吗？“脏模式”设计是否适合生产系统？如果仍然有意义，应该如何为“归一化”提出理由。

（注意：我不是在谈论数据仓库的星型/雪花模式，这种模式作为设计的一部分/需求是冗余的，但是带有后端数据库（例如StackExchange）的商业系统）

规范化的原因之一是消除数据修改异常
ORM通常不支持此操作。

我有许多Hibernate设计的数据库实例打破了这一原理：

• （肿（重复的字符串超过一亿行）
• 没有查找表（见上文）
• 没有DRI（约束，键）
• varchar聚簇索引
• 不必要的链接表（例如，当可为空的FK列足够时，强制执行1..0：1）

我见过的最糟糕的是1TB MySQL数据库，由于这些原因，它可能太大了75-80％

我还建议对大多数米老鼠系统来说，“当今的系统可以处理”这一说法是正确的。随着扩展，今天的系统将不再需要。

在上面的示例中，没有重构或更改密钥或修复数据的动力：只是抱怨数据库的增长速度以及无法在其之上构建有意义的DW

似乎他们更喜欢为每个表使用代理键，即使有些表具有主键（如“电子邮件”）-彻底破坏2NF。

代理键不会破坏2NF。2NF说：“如果列仅依赖于多值键的一部分，则将该列删除到单独的表中。”

他们规定，最好将所有内容都作为一张大表，而不管是否有大量的空值

只要遵循规范化规则，一张表中就有几列是有效的。如果要获得SQL和规范化的好处，不进行分析就合并表是不正确的。

我同意记忆约束确实与规范化有直接关系。关系范式是一个数学概念，与记忆无关。

标准化不仅可以节省内存或磁盘，还可以增加完整性。毕竟，这是一个独立于硬件的数学概念。

简单示例：假设您将学校信息维护为：

建议1：美国加利福尼亚北里奇高中

建议2：加拿大安大略省南多伦多勇士中学

如果您询问系统在安大略省的哪个位置，您会发现它在加拿大。几天后，您删除第二行，并向系统询问相同的问题，却一无所获。在此示例中，没有多少磁盘空间，内存或CPU，您将无法获得答案。

这是防止异常正常化关系的一个帮助。

编辑：根据以下评论，将多伦多一词更改为安大略。

变化越多，它们保持不变的可能性就越大。总是有懒惰的开发人员偷工减料，或者只是不知道或不想遵循最佳实践。很多时候，他们可以在较小的应用程序中摆脱它。

它曾经是将受COBOL启发的数据结构塞入早期的RDBMS中，或者是令人讨厌的dBase混乱。现在是ORM和“代码优先”。最后，这些都是人们试图找到获得工作系统的灵丹妙药而又不花“时间”认真思考自己想要和需要做什么的所有方式。匆忙一直是一个问题，而且永远是一个问题。

对于那些有意识（好运）花时间进行正确设计的人来说，数据模型将永远是最合乎逻辑的起点。数据库中存储的是有关企业关心的事物（有形和无形）的信息。 什么关于改变您的企业的烦恼要少得多快于如何您的业务运作。这就是为什么数据库通常比代码稳定得多的原因。

数据库是任何系统的合法基础，从长远来看，花时间适当地奠定基础将不可避免地使您受益。这意味着对于任何OLTP类型的应用程序，标准化始终将是重要而有用的步骤。

我同意内存约束确实与规范化直接相关...

内存限制仍然很重要。数量不是问题，速度是问题。

• 目前，CPU的速度没有变快（我们获得了更多的内核，而不是每秒的周期数）
• 现代的CPU体系结构试图通过为每个处理器（NUMA）提供单独的内存来克服速度限制。
• 片上缓存的大小没有以与主存储器相当的速度增长。
• 内存吞吐量没有大多数人期望的那么高。QPI约为25GB /秒。

一些这个地方是在覆盖当超过INT使用TINYINT？您可能会发现这很有用。我还建议遵循SQLCAT团队的@ThomasKejser（blog）的滑稽动作，因为它们倾向于处于提高数据库性能的尖锐边缘。最近的文章《 CPU缓存和内存访问模式的影响》以及有关用于极端DW规模的关系建模的SQLBits演示都是很好的例子。

我认为，归一化与反归一化之间仍然保持平衡。我完全同意ORM框架只是完成事情的方法，但我不认为这些框架会导致非规范化趋势。

仍然是需要时间效率还是空间效率的争论。在提出关系数据库理论时，磁盘存储非常昂贵，人们显然不想花那么多钱，这就是为什么当时关系数据库是在逆境中站稳脚跟的人的原因

如今情况已经大不相同了，存储空间非常便宜。因此，显然，与过去相比，我们可以忍受更多的冗余，这也是为什么BIG_TABLE方法出现了。为了寻求更多的时间效率，必须牺牲空间效率。

但是，大表方法也不是故事的结局，它仍然是时间和空间之间的平衡，就PB数据管理而言，一些开发人员也开始寻求空间效率的平衡，这就是为什么已完成将BIG-TABLE之类的数据标准化的工作。

一言以蔽之，归一化方法并不是绝对没有死，但与过去相比，它无疑被忽略了。

CJ Date在这里回答您的问题-标准化（初步）视频是免费的。

http://shop.oreilly.com/product/0636920025900.do

简短的答案：规范化是数学上正确的处理方式。如果您没有正确规范化，那么您的数据模型就是不正确的。