談談企業資訊系統資料庫設計是使用id主鍵還是uuid邏輯主鍵或業務主鍵
企業資訊系統泛指企業ERP、OA、MES等企業管理軟體，這些系統都有共性：業務層面較技術層面更加複雜，體現在資料庫上就是業務表往往欄位很多，超過4-5個欄位的業務主鍵隨處可見。從10餘年的企業資訊化系統建設及當下分散式應用出發，談談在企業資訊化系統中應該如何設計資料表主鍵。
一、資料表主鍵的演變
1、C/S階段， 業務主鍵
最初在一家國內最大民營飲料企業上班，當初大部分系統都是自建的，基於C/S架構，PowerBuilder作為客戶端直連sybase資料庫。當時，基本上所有表都是業務主鍵，比如：
1）員工表，工號就是主鍵；
2）客戶表，客戶編號就是主鍵；
3）客戶費用表，客戶號+年+月+費用項是主鍵；
為了產生工號、客戶編號等流水號，還建了一個序列號表，每次取編號都從序列號表獲取並返寫。
優點：
企業資訊系統業務上有個特點，經常會隔段時間將生產機（PRD）庫的資料導到測試庫（TST），供業務部門測試用。該階段，資料遷移非常方便，怎麼導都行。
缺點：
當時階段，真沒發現有什麼大的缺點，因為PowerBuilder datawindow 很強大，資料更新、刪除不要想開發人員寫sql（前提datawindow 構建的時候要指定好哪些是主鍵、更新哪些欄位），呼叫PFC即可。
2、B/S階段，開始使用id主鍵
隨著業務發展，有些業務經銷商（客戶）要自己做，如：報站（下訂單）、報損、費用兌現查詢等，為此上線了客戶門戶系統，B/S架構，jsp+tomcat應用伺服器+sybase資料庫。
當時，資料庫所有操作，都需要java開發人員寫sql，問題來了，更新一張業務主鍵複雜的表，sql中要寫很多where條件，工作量大，而且容易出錯。為此，部分表開始使用id主鍵，於是就可以根據ID操作單個物件了，效率、效能顯著提升。
優點：
sql操作方便，效率較高。
缺點：
資料遷移問題來了，PRD資料匯入導TST庫，不能直接使用，需要做處理。
3、分庫階段，開始使用uuid邏輯主鍵
隨著業務發展，sybase資料庫鎖機制的缺陷被逐漸放大，業務操作相互等待現象愈加明顯，於是使用了postgresql資料庫替代了sybase資料庫，不同業務使用不同postgresql資料庫，各業務基礎資料放到公用資料庫，做可忽略延遲同步。個別業務又進行了客戶分庫，內部客戶訂單走內部客戶庫，外部客戶走外部客戶庫。
一開始繼續使用ID主鍵，內部客戶訂單和外部客戶訂單需要合併時發現，id衝突，於是引入uuid邏輯主鍵，所有id關聯全部使用uuid，業務庫內部sql操作仍然可以使用id。
優點：
sql操作方便，資料遷移方便。
缺點：
sql效率略微降低，增大儲存空間，uuid產生演算法還待考驗。