数据库设计之“有时不得不违背的第三范式”

在博客园上看到了一篇关于数据库范式的文章《数据库设计中的五个范式》：
第三范式规则查找以消除没有直接依赖于第一范式和第二范式形成的表的主键的属性。我们为没有与表的主键关联的所有信息建立了一张新表。每张新表保存了来自源表的信息和它们所依赖的主键。  
关于第三范式的思想，我想有很多朋友都熟悉，在数据库设计时，也是我们尽可能采用的范式之一，第三范式的出发点是什么？就是尽可能的减小“数据冗余”、并也能得到“数据”的整洁性，提高维护性，不容怀疑，第三范式是我们努力、必须要去遵从的。
然而，有很多朋友把第三范式作为“不死的法宝”，但其实在实际的应用中，我们还是要从不同的业务出发，要合理的应用“第三范式”。下面我也就简单的举个例子：
    一张订单会关联很多的基础资料，如：客户，付款条款，货运方式等，这些信息是有专门表进行维护的，在下订单时也是用下拉框选择的，在保存订单信息时,按照“第三范式”的要求，那应该只保存对应的主键值就OK了。因为这样可以避免数据冗余，但对我来说，我不会这样做，我会把客户的名称、联系电话、付款条款名称等订单上要求记录的信息直接COPY到订单的表中。
   这样看来，我们违背了“第三范式”，是的，但在这里，我们违背“第三范式”也是有理由的：
   1我不想在订单下达完以后，删除了某条付款条款，导致这些订单无法知道“真实的付款条款”了，这肯定不合理。
   2我也不想，因为下了这张订单了，而“严格控制”付款条款的“删除”功能，这也不合理，凭啥不能删除了？下个月这个“条款”确实永远不会采用了。
   3我也不想，付款条款修改后，导致以前所有采用此付款条款的订单都变成新的条款，那在系统中的订单如何与手头的纸张订单再对应，这肯定也不合理。

  所以，我的设计原则是，对于这种订单我们应该采用“隔离”的方式来对待，让基础数据COPY到订单中，这当然会违背所谓的“第三范式”，但这也是实际的需要啊。理论与实际是有差别的。
  订单--这种在现实中以实物的方式存在，实物具有与基础数据的参考性，而不是关联性，基础数据只能是作为订单这个实物的一个“参考”，而不是“关联”，这可以称为“独立性”;再者，订单具有一定的历史性，因为是实物，在实际的过程中，是即时生成的，那么在生成的当时去参考了基础数据，订单就在当时被确定，确对不能因为基础数据的修改而导致订单被“无辜变性”了，这也就是订单的“历史性”，当以后翻阅这些纸张订单时也能对应上系统里的订单。

   这是我所理解的最典型的例子，在实际的系统设计中，我们应该多思考一下，是不是要采用“第三范式”，不要再盲目追捧了。


本文来自CSDN博客http://blog.csdn.net/Secreter/archive/2009/06/23/4292211.aspx