今天在做專案的資料庫設計時，突然發現自己在表的主鍵設定方面太過片面，對於邏輯主鍵和聯合主鍵的理解也很少。索性上網百度了一下，看到了一些論壇中的兄弟們的討論，其中很多的分析讓我頓時清醒了很多。下面開始貼上一些人的觀點和分析，如果原作者看到本文，發現有不妥之處，請郵件告之。
 
網友goldrain說：
我倒不反對業務主鍵,但只指單一欄位做主鍵,比如很多登陸系統,常就用loginName做使用者表主鍵,而且這麼做很方便,我覺得只要是值唯一而且不改動的欄位就可以做主鍵; 不過覺得聯合主鍵確實多餘,這時用單一欄位的邏輯主鍵取代聯合主鍵,對定位記錄的速度,對開發特別是hibernate開發會很方便; 我的觀點都是從自己開發方便角度講的.  
網友magician說：
我覺得邏輯主鍵和聯合主鍵用途不一樣：

如一個囚犯，進監獄就會給他一個邏輯主鍵，比如9527，但他外面混的朋友可能並不知道這個邏輯主鍵，而只有他的一些其他資訊，比如姓名、年齡、外貌、所做的事情等等，這些感觀上的東西構成的可以認為是聯合主鍵。

如何評價這兩者誰好？我只能說，應用範圍不一樣。但不可否認，9527非常清晰！（當然我不願意人家這樣叫我.......） 

還有就是，你說用聯合主鍵做出來的東西執行得很好，所以你沒有道理要用邏輯主鍵。從你的實際情況而言，你這麼說沒錯，但從邏輯思維的角度，你大錯而特錯：存在並不一定合理。不過在你自己還沒有找到使用邏輯主鍵的理由之前，我完全贊同你不要去修改現有系統這一英明的決定。 

再者，浪費很多空間？呵呵，我不認為一個類似於銀行這樣系統還會在於有一個欄位引起的空間問題，假如這個欄位給你帶來的是設計的合理和操作的快捷的話，請注意我用的是假如。當然，你可以更感性的瞭解一些資料，看看每個表多一個int欄位會帶來多大的空間上的損失。我覺得空間這個東西，不是在這個層面需要考慮的問題。其實，我現在在做任何系統的設計，都不會考慮硬體空間的問題。 

至於更具體，比如對你們的系統性能究竟有多大影響，設計上有多大影響，現有系統改動量有多大，那是你應該考慮的問題。

另：Hibernate不一定要用邏輯主鍵  再另：不一定要用Hibernate！
 
網友xiaoyu說：
用邏輯還是業務,隨便你的,不過舊系統是不要用HB,HB也支援複合主鍵. 

主要是作了主鍵後就不能修改,這個蠻麻煩的.....唉.. 

記得那年,公司有出了一個主意,想要一個定單的系統,於是我就去調研(公司只有我一個開發員,客戶就是下面的員工),我說產口是不是有一個固定的產品號,是不是不會重複的(好象地球人都知道),那定單是不是有一個訂單號,也是固定的,不會重複,她們回答的時候是多麼爽快呀(好象在逗小孩子). 

我就用Access建了表(就公司用,所以沒有選擇其它的資料庫),主鍵:用了產品號,用了訂單號.又因為她們超喜歡excel,就用了VBA..... 

系統運行了一段時間,後來產品的編號要改掉了,全部的產品號要在前面多加個LP開頭的.....我頓時

[email protected]#$%^&*( OK,我只好用insert into XXXX (select XXX) (還是產品號為主鍵). . . 網友xj2ee說：
1、從純資料庫設計的角度來看： 
使用業務主鍵是自然的選擇，但如果業務發生變化引起業務主鍵的變化怎麼辦？（xiaoyu舉的例子），所以引入邏輯主鍵id（當然不是每張表都要），浪費空間之說我認為是沒有必要考慮的，儲存技術的發展能容忍這點小浪費。而且單一的id在多表關聯時，顯然比複合主鍵有更好的效能。 
2、從WEB應用開發的角度來看： 
用邏輯主鍵你只需要在頁面和後臺之間傳遞一個單一的引數，簡化了開發工作，而且有較高的查詢效率。 
3、從Hibernate應用的角度來說： 
複合主鍵需要更多的處理，效能不高，所以Hibernate不提倡用複合主鍵。