很久都沒有寫過博客了，從最后一次發表的文章到現在已經是兩個多月的時間了，一直都想寫點什么，可一直沒有時間（其實都是借口），隨筆內容無疑就是工作學習中的總結，經驗的分享，也是自己成長的一面鏡子，好了，言規正傳，這次談談在數據庫設計中主鍵字段類型的選擇。
做web 開發時，經常要與數據庫交互，數據庫主鍵的選擇也猶為重要，怎么么選擇數據庫主鍵字段的類型，主要從以下幾個方面考慮：
1. 首先要符合業務需求，這是設計中重要的出發點
2. 數據庫的遷移問題，考慮在后期是否要經常遷移，數據庫高度唯一性
3.程度中的使用是否更簡單，易用（比如分頁，一般是根據主鍵查詢來分頁的）
4.數據庫查詢的效率，在主鍵做為外鍵鏈表查詢的時候
根據以上的情況，通常數據庫主鍵字段的類型常被設計成 int 或 GUID 或自定義的格式類型，以下詳細說明這幾種的區別和應用的場合
1. 主鍵字段類型設置成 int 類型
這種情況主要考慮到程序的分頁，排序（按主鍵字段的遞增或遞減），簡潔易懂，同時可加rowguidcol列，如果是SQL 2005可以使用NewSequentialid()來順序生成，為同步做准備，數據合並時也可以作為參考。主從表關聯速度會快一點。小庫推薦。
2.主鍵字段類型設置成 GUID 類型
這種情況主要考慮到對數據有強烈的唯一性要求，比如用戶表的主鍵類型都被設置成 GUID,其它的表的主鍵類型也都應該設置成GUID,嚴格避免數據重復，並易於定位;數據要經常遷移，如果是 int 類型，容易造成混亂;有若干個表飲食類似的數據，有時要對這些數據做合並或其它處理，這時GUID 類型是最好的選擇
總結：
使用GUID。不存在重復問題，數據合並時非常簡單。關聯速度比int慢。經常合並數據或脫機輸入數據聯機上傳最好用此方案。
guid 數值是隨機的，而且不接受可以對使用者更具意義的任何形式。沒有辦法判定產生 guid 值的順序，所以不適合用於現有依循環次序遞增索引鍵值的應用程序
這兩方案根據不同需求選擇。