關於這個問題網上已經有很多的討論，現在綜合這些討論在加上自己眾多建模及資料倉儲工作中的經驗給出以下分析及取捨建議，供各位同行參考：
一、業務的東西，是每乙個做軟體的最薄弱的，並且是最有可能受到客戶影響的，也是最會引起問題的。
比如身份證，如果有系統的錶用此做主鍵，其他眾多表以此為外來鍵，當身份證從15位公升到18位時，整個數系統的重構將是乙個非常困難的工作。乙個系統在維護的成本遠大於開發的成本，所以要充分考慮客戶業務變更的需求,使用者今天說不會變，而明天可能就變了,即使使用者已經對需求確認簽字。這些都是不可預知的。
二、業務主鍵在存在主從關係時候，更新時不方便(這樣你必須要檢查從表，再處理主表)。
三、業務主鍵是複合型時，crud操作時不方便(比如要定位一條記錄時必須傳入復合的每個字段,
四、使用業務主鍵，基於源資料的質量問題，往往存在業務主鍵重複,對於源資料可控及資料量小的操作,業務主鍵重複還容易控制，而對於某些高度耦合的系統來說， 後果是不堪設想的。
五、資料倉儲的表中的冗餘字段不是很少而是大量的,增加邏輯主鍵並不是冗餘的根源。
建議設計的基本原則（具體情況可能要具體分析）：
一、對於業務資料，最好採用邏輯主鍵;
二、對於業務復合主鍵有多個字段(>3?)，需要採用邏輯主鍵;
三、對於基礎資料，基於多方面考慮，是可以採用業務主鍵的。這類表初始化以後資料不會經常發生改變。
四、取消業務主鍵後，在查詢經常會用到的相關的業務字段建立index，可以提高查詢效率;
五、使用邏輯主鍵,表的業務資料唯一性由程式來檢查控制，使業務資料重複這類髒資料控制在業務允許的範圍;
六、業務資料的重複這類髒資料也可以通過分析結果資料得到;
七、業務資料的邏輯主鍵使用numeric自增長型，在遷移資料時，取消目標表的自增長，資料遷移完成後，再重建邏輯主鍵。
什麼是邏輯主鍵和業務主鍵
定義 邏輯主鍵 surrogate key 無意義的字段，即自增長字段，即identity。這其中還有乙個選擇guid globally unique identifier 也叫 主鍵。業務主鍵 natrual key 有意義的字段，比如身份證 id。也叫自然主鍵 維基百科介紹 在關聯式資料庫設計中...
聯合主鍵和復合主鍵
聯合主鍵其實就是中間表。在多對多模型裡，需要兩個表中的主鍵組成聯合主鍵，這樣就可以查到兩個表中的每個資料。建立team表 create table team id mediumint auto increment comment team 主鍵 name varchar 10 comment tea...
mysql關於主鍵和索引
一 主鍵和索引的區別 主鍵 惟一地標識一行，作為乙個可以被外來鍵有效引用的物件。二 索引的建立 檢視 刪除 mysql create index 索引名 on 表名 欄位名 100 text欄位要指定長度，可以小於實際長度 mysql show index from 表名 mysql drop 索引...