Posted on 2008-04-14 20:44
leekiang 閱讀(1233)
評論(0) 編輯 收藏 所屬分類:
架構設計
http://www.javaeye.com/topic/124612
http://www.javaeye.com/topic/2832
http://www.javaeye.com/topic/8283
http://www.javaeye.com/topic/151187
http://www.javaeye.com/topic/2312
http://www.itpub.net/viewthread.php?tid=510215&extra=&page=1
以下摘幾個我自己認同的觀點:
1,
其實有一段時間我們的開發人員也有這種想法，以為程序可以控制好
后來發現沒有外鍵的表里經常有垃圾數據（找不到父親的孩子），然后又把外鍵一一加上去，后面測試才發現是應用的BUG，在特定情況下才會發生的BUG。
如果沒有外鍵那數據庫就不會報錯，也就是說垃圾數據不能阻止。
2,在復雜的業務邏輯下，程序來保證這個是極不可靠的，只有交給數據庫從底層來保證才能避免出錯。
當然，如果是穩定的程序中把外鍵去掉會怎么樣，這又是另一回事了。
外鍵的存在對數據庫的維護來說是有一些不方便的地方。
3,我們以前做開發的時候，在開發、測試階段，是所有業務邏輯需要的外鍵都加上的。數據量小，并發少，也無所謂什么性能什么的。等測試和試運行一段時間后，再將外鍵去掉，以提高性能。
4,怎么這么多人不用外鍵的，外鍵可是邏輯的約束啊！說外鍵影響性能，可以denormalize外鍵表啊，但是插入更新必須要符合約束啊，我覺得這是不可替代的啊
對數據的約束最好盡可能放到db里，集中管理清晰準確，以前吃過應用管理約束的虧，不過好好看看oracle sap這些范式做的都還不錯啊，他們都這樣做我想多少能說明點問題吧
5,你看看oracle系統數據表的設計,再看看大型數據庫表的設計,
你就明白,外鍵約束無處不在.
6,該用的地方，就一定要用！前幾天我們的應用程序發現一個bug，后來我仔細一查，就是由于沒有使用外建，數據不匹配導致的。教訓深刻！
7,如果現在要我來選擇，我決定是要用的一定要用，這是系統設計的嚴謹性的要求，不然產生一堆垃圾數據，這是在一個好的系統中是不允許的。
8,呵呵，做過開發的ＤＢＡ應該都會有這樣的體會
當統計報表中的數據不對的時候就知道什么叫問題嚴重了，要一點點數據去核查。
9,最好還是使用數據庫外鍵這個最直觀的功能吧
至于性能不知有沒有什么測試數據，究竟能慢到什么程度，不要聽說會慢就不用吧（呵呵，從ＴＯＭ的書里學到的）
10,這要看是建立那中類型的數據庫了
如果是操作類型的數據庫 OLTP 面向應用的
數據的規范化是很有必要的.. 該用外鍵的情況一定要用.
如果是面向部門 用于OLAP或建立數據倉庫.
這種時候 往往需要反規范化 存取效率是首要因素
我自己的結論:
如果是做企業級的OLTP應用，并且數據量不是非常大的話，一定要建外鍵。畢竟對于企業來說，保證數據的正確性是最重要的。但如果經過長時間的運行證明代碼可靠、并且數據量已經很大，這時也可以去掉外鍵以提高運行速度。