資料表主健通常採用以下三種方式：
1.自動遞增值。 2.
唯一名稱。這個是使用自己定義的演算法來生成乙個唯一序列號。 3.
guid
（全域性唯一識別符號）。
在客戶端生成，由
guid
的特性決定，通過
guid
生成的值可能出現重複的機會幾乎等於零，因此保證在插入表的時候主鍵值唯一。
可以方便處理分布式資料的提交，比如：分店資料向總店提交――直接將該部分資料插入即可。
在資料庫伺服器端生成，由於該值是由資料庫系統內部處理的，亦保證其唯一性，但由於其是在資料庫伺服器端生成，因此必須將該值返回客戶端，客戶端通過該值過行其它操作。比如一張單據（主從表）是使用自動遞增值，當插入單據抬頭後，必須將單據抬頭的關鍵字段值返回，再插入單據明細（單據明細是通過單據抬頭關鍵字段進行關聯的）。
不能很好處理分布式資料的提交，比如：分店資料向總店提交――提交資料時必須重新生成該資料表的關鍵字段值，以保證該字段值唯一。
要支援離線資料處理需要進行額外的處理，對本地資料報進行儲存記錄（儲存到本地）時需要插入乙個假設唯一值，在提交離線資料回資料伺服器時再重新生成真正的唯一值，並重新進行相關的處理。
在客戶端生成或在服務端生成，相對於自動遞增值不同的地方就是自己維護生成唯一值的演算法及所儲存的臨時值，容易造成出錯或其它問題。如果是在客戶端生成唯一值的話，還必須保證所生成的值是唯一的。
不能很好處理分布式資料的提交，比如：分店資料向總店提交――提交資料時必須重新生成（或預先處理）該資料表的關鍵字段值，以保證該字段值唯一
要支援離線資料處理需要進行額外的處理，對本地資料報進行儲存記錄（儲存到本地）時需要插入乙個假設唯一值，在提交離線資料回資料伺服器時再重新生成真正的唯一值，並重新進行相關的處理。
下面以乙個新增單據儲存比較
guid
與自動遞增值／唯一名稱的差別
動作
guid
自動遞增值／唯一名稱
單據抬頭
新增單據抬頭關鍵字段值：獲取並填寫
單據抬頭關鍵字段值：無
儲存直接儲存
首先獲取並填寫關鍵字段值，然後再進行儲存
返回直接返回
返回時必須將關鍵字段值返回
單據明細
新增關聯單據抬頭字段值：直接填寫
單據明細關鍵字段值：獲取並填寫
關聯單據抬頭字段值：無
單據明細關鍵字段值：無 儲存
直接儲存
獲取單據抬頭關鍵字段值並填寫到單據明細的關聯單據抬頭字段中；
然後獲取並填寫單據明細關鍵字段值；
再進行儲存
綜合以上所述，用
guid
作為資料表的關鍵字段值是可以減輕關鍵字段相關的操作的，並且是最直接實用的方法。
使用GUID作為資料庫主鍵的測試
今天聽了msdn的webcast，是關於entlib的資料訪問的講座，末尾我問了兩個自己所關心的問題 在乙個較大型的應用中，如果需要用到兩套以上的資料庫 如 sql server和oracle 是否可以把需要的sql查詢全部封裝在儲存過程裡，這樣就只需要一套訪問 了，有沒有更好的方法解決這個問題？在...
使用GUID作為資料庫主鍵的測試
今天聽了msdn的webcast，是關於entlib的資料訪問的講座，末尾我問了兩個自己所關心的問題 在乙個較大型的應用中，如果需要用到兩套以上的資料庫 如 sql server和oracle 是否可以把需要的sql查詢全部封裝在儲存過程裡，這樣就只需要一套訪問 了，有沒有更好的方法解決這個問題？在...
SQL取資料表主鍵
1 select table name,column name from information schema.key column usage where table name dtproperties 2 exec sp pkeys table name 表名 3 select o.name a...