讓人讨厭的 primaryKey = MAX(Id) + 1 讨厭、讨厭、讨厭

最近檢查代碼品質、看到有寫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：将來是否好維護好擴充？

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

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

一步步教你如何用瘋狂.NET架構中的通用權限系統 -- 如何控制使用者顯示的菜單權限

一步步教你如何用瘋狂.NET架構中的通用權限系統 -- 在頁面中的調用權限講解

一步步教你如何用瘋狂.NET架構中的通用權限系統 -- 資料集權限的調用權限講解

一步步教你如何用瘋狂.NET架構中的通用權限系統 -- 分級管理

一步步教你如何用瘋狂.NET架構中的通用權限系統 -- 分級授權

瘋狂.NET 通用權限設計 C\S背景管理，B\S前台調用源碼樣例程式×××之 --- 操作權限

瘋狂.NET 通用權限設計 C\S背景管理，B\S前台調用源碼樣例程式×××之 --- 角色權限

瘋狂.NET 通用權限設計 C\S背景管理，B\S前台調用源碼樣例程式×××之 --- 資料集權限

将權限管理、工作流管理做到我能力的極緻，一個人隻能做好那麼很少的幾件事情。