几星期前，Pat Helland在其博客给出一个简短介绍，称“正规化适合于胆小鬼”。Pat一开始就声称（很明显）我们正规化是为了避免更新异常，但接下来做出了一系列有趣的短评：

• 许多类型的计算问题本质上是只增（Append-Only）的，用他的话来说是“会计不使用橡皮擦”。因此，对于不变的数据没有必要去进行正规化（除非你真的需要那些空间）。
• 开发者使用“完整的”业务对象来工作。这些业务对象总是反正规化的完整视图。

    作为另一个博客，你可以很容易驳回Pat的言论——除非你注意到Pat有与数据库系统长期为伍的经历，这包括，如作为SQL Server Service Broker的首席架构师、COM+团队的奠基人之一。Pat还花了几年时间为Amazon工作——并且Werner Vogels（Amazon的CTO）确实提过可以考虑反正规化实体，以得到更好的伸缩性和效率。这些言论是他在QCon上关于可用性和一致性（最近发布于此）的演讲中提及的。

    Andres Aguiar评论说，除了“无需正规化不变数据”，你甚至都不需要删除数据：

另一个想法是，你事实上都不需要删除/更新数据库。“删除”一行意味着设置InvalidationTimestamp = now()，更新一行意味着设置InvalidationTimestamp = now()的同时新增一行，使其SinceTimestamp= now()且InvalidationTimestamp = null（你实际上需要两组日期，这将在另一篇帖子里讨论）。现在，如果你把两个想法合在一起，那么所有的数据都是不变的，所以你不需要正规化任何东西。

    通过分析这一点，Andres提到一个障碍：这种情形下会使每张表产生大量数据行（译注：原文是column，但根据上下文的意思，应该是数据行才更有意义。），而数据库并未准备好应对这种情形。如果你归档更老的数据，那么它是可以得到解决的。

Dare Obasanjo认为

“数据库反正规化是一种效率优化，但这应该作为最后一道防线。应该在创建数据库索引、使用SQL视图和实现应用特定的内存缓存之后。”

    然而，Dare认同：当你需要大规模计算时，你可能需要反正规化，并举Flickr为例。

    正如Cal Henderson（Flickr的Web开发领导）在2004年关于Flickr架构演讲中所说的：Join效率低下（27页）。作为结论：

* 正规化的数据适合于胆小鬼
* 多处保存数据的多重副本
* 让搜索更快些
* 必须在应用逻辑中确保一致性

    一篇由Jason Kottke于2004年撰写的博文中，表露出了与Pat的博文和Cal演讲中第一点类似的观点。Jason解释，在Flickr的情形中，每次Insert/Delete或Update会有13次Select，这是他们为什么选择反正规化的原因。

Pat在其介绍的结尾总结：

“人们正规化‘因为他们的教授这么说的’”

    是时候反思数据库正规化的咒语了吗？一些更大的网站似乎这么认为，你的感觉呢？

原文地址：http://www.infoq.com/cn/news/2007/08/denormalization