在博客園上看到了一篇關(guān)于數(shù)據(jù)庫范式的文章《數(shù)據(jù)庫設計中的五個范式》：
 第三范式規(guī)則查找以消除沒有直接依賴于第一范式和第二范式形成的表的主鍵的屬性。我們?yōu)闆]有與表的主鍵關(guān)聯(lián)的所有信息建立了一張新表。每張新表保存了來自源表的信息和它們所依賴的主鍵。  
 關(guān)于第三范式的思想，我想有很多朋友都熟悉，在數(shù)據(jù)庫設計時，也是我們盡可能采用的范式之一，第三范式的出發(fā)點是什么？就是盡可能的減小“數(shù)據(jù)冗余”、并也能得到“數(shù)據(jù)”的整潔性，提高維護性，不容懷疑，第三范式是我們努力、必須要去遵從的。
 然而，有很多朋友把第三范式作為“不死的法寶”，但其實在實際的應用中，我們還是要從不同的業(yè)務出發(fā)，要合理的應用“第三范式”。下面我也就簡單的舉個例子：
    一張訂單會關(guān)聯(lián)很多的基礎資料，如：客戶，付款條款，貨運方式等，這些信息是有專門表進行維護的，在下訂單時也是用下拉框選擇的，在保存訂單信息時,按照“第三范式”的要求，那應該只保存對應的主鍵值就OK了。因為這樣可以避免數(shù)據(jù)冗余，但對我來說，我不會這樣做，我會把客戶的名稱、聯(lián)系電話、付款條款名稱等訂單上要求記錄的信息直接COPY到訂單的表中。
   這樣看來，我們違背了“第三范式”，是的，但在這里，我們違背“第三范式”也是有理由的：
   1我不想在訂單下達完以后，刪除了某條付款條款，導致這些訂單無法知道“真實的付款條款”了，這肯定不合理。
   2我也不想，因為下了這張訂單了，而“嚴格控制”付款條款的“刪除”功能，這也不合理，憑啥不能刪除了？下個月這個“條款”確實永遠不會采用了。
   3我也不想，付款條款修改后，導致以前所有采用此付款條款的訂單都變成新的條款，那在系統(tǒng)中的訂單如何與手頭的紙張訂單再對應，這肯定也不合理。

  所以，我的設計原則是，對于這種訂單我們應該采用“隔離”的方式來對待，讓基礎數(shù)據(jù)COPY到訂單中，這當然會違背所謂的“第三范式”，但這也是實際的需要啊。理論與實際是有差別的。
  訂單--這種在現(xiàn)實中以實物的方式存在，實物具有與基礎數(shù)據(jù)的參考性，而不是關(guān)聯(lián)性，基礎數(shù)據(jù)只能是作為訂單這個實物的一個“參考”，而不是“關(guān)聯(lián)”，這可以稱為“獨立性”;再者，訂單具有一定的歷史性，因為是實物，在實際的過程中，是即時生成的，那么在生成的當時去參考了基礎數(shù)據(jù)，訂單就在當時被確定，確對不能因為基礎數(shù)據(jù)的修改而導致訂單被“無辜變性”了，這也就是訂單的“歷史性”，當以后翻閱這些紙張訂單時也能對應上系統(tǒng)里的訂單。

   這是我所理解的最典型的例子，在實際的系統(tǒng)設計中，我們應該多思考一下，是不是要采用“第三范式”，不要再盲目追捧了。

  以上純屬我個人意見，僅供參考，歡迎大家討論。