關於資料庫表應該採用邏輯主鍵還是業務主鍵的討論

昨天令狐因為處理動網論壇的資料庫時，發現它是用文章號來作為主鍵，由於無意中對它作了一些修改，導致文章的關聯變得混亂了。於是我們討論了一下資料庫表中主鍵的選擇問題。因為對動網論壇的程式不熟，所以我也不知道它是怎麼設計實現的，今天令狐把JavaEye上的一個關於這個方面的話題拿來討論就好辦了。

我起初也覺得用一個無意義的邏輯主鍵是一個好辦法，至少說用一個欄位就可以唯確定一條記錄，使用上會很方便，速度應該也會快些。但是看了JavaEye那個帖裡的討論，以及在QQ群裡的討論後，我發現不完全是這樣的。

其實這是兩種不同的設計思路，談不上用邏輯主鍵一定比用業務主鍵好。

用業務主鍵是傳統的C/S應用開發的思路，包括我現在用的SAP裡，也大量使用業務主鍵。但如果用O/R Mapping，則可能用邏輯主鍵好一些。

因
為對於傳統C/S應用來說，以典型的兩層結構看，前端處理的是一個資料表示的工作，後端處理的是一個資料持久化的工作。商務邏輯分散在兩端，特別是在後
端。因為需要在後端通過Stored
Procedure和View等來實現商務邏輯，應用直接與關聯式資料庫打交道，所以資料的記錄不但要求便於程式訪問，對開發人員來說，還要易讀。也就是說需
要資料庫的關係邏輯能夠清晰地表達出商務邏輯來。主鍵採用業務主鍵是自然甚至是必須的。

而ORM應用恰恰相反。它需要一個最簡單的
辦法來標記一條唯一記錄，但不需要有具體的意義，就像在OOP中，我們訪問一個Object總是通過指標（或相似的引用），但我們並不需要知道這個指標具
體的值是0x89ABCDEF還是0xFEDCBA98。邏輯主鍵就相當於一個指標，當別的關聯表引用到這條記錄時，用一個外鍵欄位記錄了這個邏輯主鍵，
就相當於那個Object中有一個屬性記錄了一個指向這個Object的指標。這時如果用業務主鍵--特別是複合業務主鍵--就是存心給自己打麻煩了。最
糟糕的情況就是當需要修改這個業務主鍵的值的時候，會導致所有的關聯發生混亂--在傳統C/S應用中，我們是用Trigger來解決這個問題，但是在
ORM中不可能這樣做，否則那還要ORM幹什嗎？

當然，對於開發人員來說，在ORM這樣的情況下，用邏輯主鍵存在一個至關重要的問題
就在於資料的可讀性將要變差。也就是說，除非通過OO的視角來看資料才是易於理解的。但如果直接進入後端看關聯式資料庫，將變得困難。因此，基本上，邏輯主
鍵與ORM是相輔相成的，缺一不可，並且採用ORM的開發人員要儘可能避免與後端的關係資料打交道，否則就會非常的痛苦。

正如令狐所作的總結：一個是從OO角度看，一個是直接深入資料庫內部看。