最近檢查程式碼質量、看到有寫primaryKey = MAX(Id) + 1的做法，總讓我有些不爽，雖然是新聞類的網站，對主鍵的要求不是很嚴格，關聯的資料也不復雜，但是總覺得這樣的做法，不是很妥當。

   原因之一：

   若這個表裡的資料很多很多，索引也沒有建立好，MAX(Id)的執行效率不會非常高，當然這樣的情況比較少發生，但是有的時候這個做法也會引起一些併發問題，當然是一個表裡插入時會很少發生這樣的問題，若有相關的子表什麼的，很可能會引起併發衝突等，當然我們也不希望總是遇到那種複雜的情況，總的來說不是很穩妥。

   原因之二：

   很早很早的時候，做OA專案，那時候也沒大主意，主鍵就靠這個產生，主表產生了1、2、3、4、5，然後5被刪除了，重新又生成了5這個主鍵，但是莫名其妙的，5個子表沒對上，原因雖然是出在我們程式沒處理好，當5被刪除時，子表裡的資料忘記被刪除了，若是子表又有子表，那這個問題就更復雜了，每次寫程式都能寫得天衣無縫還是比較困難的，當然後來不直接刪除資料了，只是打上了刪除標記，雖然這個問題被間接的解決了，但是總是覺得這樣產生主鍵的方式不是很妥，總是會引起一些沒必要的麻煩。

   原因之三：

   若一個公司有2個分公司，每個分公司都有自己的資訊系統，總公司需要把資料進行合併，這時候大家產生的主鍵都是1、2、3、4，不好合並資料，把資料直接匯入到一起，會引起額外的麻煩，這時候主鍵是越簡單越好，表結構也是越簡單越好原則，能直接把資料庫放到一個表裡，其他什麼也不管了是最理想的處理方式。

   原因之四：

   以前的某個公司，做一個醫院的專案，由於系統不穩定，導致給A病人開的藥會跑到B病人哪裡去，開始測試階段發現了幾次這樣的現象發生後，這個系統就被廢棄了，這搞不好是要出人命的呀，我估計，其中一個關鍵問題，就是資料的關聯主鍵沒處理好，導致主鍵產生的演算法不嚴謹，關聯關係有漏洞，導致這個專案失敗的原因會很大，雖然我沒看過人家的原始碼，也沒參與這個專案，但是多年的職業感覺告訴我，主鍵上出問題了，主外來鍵關係是一個管理系統的命脈。

   雖然主外來鍵關係是一個很簡單的東西，但是這個東西做得天衣無縫、讓人覺得心服口服，效率又高，思路又嚴謹就很難了。

   1：是否能保證唯一性？併發情況下？分散式執行情況下？  

   2：執行效率問題，主鍵產生的速度足夠快？

   3：主鍵是否能適當保證資訊的安全性？ 1，2，3，4，傻瓜都能猜測出來，下一個是5？6？7？

   4：主鍵演算法能否支援多資料庫，越簡單相容越好。

   5：別人是否好呼叫你的主鍵產生演算法？

   6：是否在一定程度上避免了錯誤產生的可能性，例如程式設計師比嚴謹導致的業務上的重大錯誤，例如醫院的那個？

   7：將來是否好維護好擴充套件？

   隨便說說吧，到目前為止看了很多主鍵的產生演算法、做法，真的做得很圓滿，很不容易，把一個簡單的東西徹底吃透很不容易，能知道存在哪些問題，哪些不足也很難，天天想著去改進了，天天想著問題會在哪裡也很難。

   其實很多問題，都在我們的工作中存在，我們需要把工作中的問題，一個個都解決好，避免給客戶造成重大損失，能解決工作中的缺陷漏洞才是人才，而不是學到死了，也沒做出啥玩意兒來，強很多，學那麼多，就是為了在工作中用到，解決工作中的點點滴滴問題，小問題太多了最終就全盤崩潰了。