關於使用GUID和Identity做主鍵的一些思考

  

通常，給資料庫中的表都添加一個“無意義”的主鍵，能夠大大地簡化程式的開發。這個主鍵用什麼類型呢？其實各種類型，只要大小不超過900位元組都可以，但我們最常面臨的兩種選擇是——GUID（UniqueIdentifity）和Identity INT。

《ADO.NET 2.0進階編程》一書的“5.2.2 選擇主鍵”一節，對此進行了一些對比，並推薦使用GUID類型作為主鍵的類型。但本文中老劉將介紹自己在實際開發中的一些感觸。

老劉在公司寫程式時，面對的資料庫絕大多數都是用Identity做主鍵；而回家自己寫程式玩的時候，因為迷信《ADO.NET 2.0進階編程》，所以設計的資料庫都採用GUID做主鍵類型。所以，對這兩種主鍵類型都有些想法。

GUID優於Identify的方面

首先，對於GUID類型的主鍵，通常在建立新的資料條目時可以採用Guid.NewGuid()方法為其產生主鍵；而對於Identify類型的主鍵，只有當資料條目被真正插入資料庫後才能得到其主索引值。當需要在同一個事務中，向多個相關表中插入資料時，若採用GUID主鍵，就能使用一次提交動作插入所有資料；而如果使用Identify類型做主鍵，就必須先插入主鍵列所在表的資料，再插入外鍵列所在表的資料。如下面兩段代碼所示。

// 使用GUID作為主鍵類型
using(MyDataContext db = new MyDataContext())
{
    Category c = new Category
    {
        Id = Guid.NewGuid(),
        Name = "分類1"
    };
    Article a = new Article
    {
        Id = Guid.NewGuid(),
        Title = "標題1",
        Body = "內容",
        CategoryId = c.Id    // Category對象的Id已經確定
    };
    db.Categories.InsertOnSubmit(c);
    db.Articles.InsertOnSubmit(a);

    db.SubmitChanges();    // 一次提交，如果出現錯誤自動全部復原
}

// 使用Identity作為主鍵類型
using(MyDataContext db = new MyDataContext())
{
    Category c = new Category    // 由於才用Identity類型作為主鍵，所以無需也不能明確指定主索引值
    {
        Name = "分類2"
    };
    db.Categories.InsertOnSubmit(c);
    db.SubmitChanges();    // 提交後才能得到確定的ID值

    Article a = new Article
    {
        Title = "標題又來了",
        Body = "沒有內容",
        CategoryId = c.Id
    };
    db.Articles.InsertOnSubmit(a);
    db.SubmitChanges(a);    // 第二個提交，如果出錯，分類c也會留在資料庫中
}

複製代碼

正如注釋中所述，當發生錯誤時，一次提交可以簡單乾淨地復原；但多次提交，就得採取一些手段了。

Identify優於GUID的方面

首先，Identify根本上說是一個int，只佔4位元組；而GUID要佔16位元組。這當然不算什麼，可以忽略。

其次，要知道，主鍵就是一個簇索引（叢集索引），這意味著資料在磁碟上的物理排列順序是和主鍵順序一樣的。這就存在一個問題，每次產生的GUID並不是按照時間順序從小到大的，換句話說，第二次產生的GUID可能比第一次小，而第三次可能又比第二次小。這就導致每次插入一行資料時，都要對錶中整行整行的資料進行排序。而Identify類型的欄位，可以明確保障後產生的值比之前產生的值都大，因此新插入的資料會簡單地追加在表的尾部。所以，對於頻繁插入新資料的表來說，Identify主鍵的效能要好一些。（注意，本條純屬老劉推測，沒有進行過測試。）

最後，Identify主鍵更便於人類閱讀。嗯……給大家各情境吧。在公司，我沒有查看生產環境資料庫的許可權，所以當客戶提交來bug之後，我會朝我老闆喊：幫我把伺服器上ID是1234的使用者的資料取出來我看看~~  想想吧，如果採用了GUID主鍵，我該怎麼喊？

-----

注，寫到這裡，就完了。但我發現好像有些傾向於Identify主鍵。希望大家不要有這樣的偏見，好好看看《ADO.NET 2.0進階編程》，考慮考慮。歡迎大家在這裡探討。

 

轉自：http://www.cnblogs.com/AndersLiu/archive/2008/07/03/primer-key-guid-vs-identify-int.html

通常，給資料庫中的表都添加一個“無意義”的主鍵，能夠大大地簡化程式的開發。這個主鍵用什麼類型呢？其實各種類型，只要大小不超過900位元組都可以，但我們最常面臨的兩種選擇是——GUID（UniqueIdentifity）和Identity INT。

《ADO.NET 2.0進階編程》一書的“5.2.2 選擇主鍵”一節，對此進行了一些對比，並推薦使用GUID類型作為主鍵的類型。但本文中老劉將介紹自己在實際開發中的一些感觸。

老劉在公司寫程式時，面對的資料庫絕大多數都是用Identity做主鍵；而回家自己寫程式玩的時候，因為迷信《ADO.NET 2.0進階編程》，所以設計的資料庫都採用GUID做主鍵類型。所以，對這兩種主鍵類型都有些想法。

GUID優於Identify的方面

首先，對於GUID類型的主鍵，通常在建立新的資料條目時可以採用Guid.NewGuid()方法為其產生主鍵；而對於Identify類型的主鍵，只有當資料條目被真正插入資料庫後才能得到其主索引值。當需要在同一個事務中，向多個相關表中插入資料時，若採用GUID主鍵，就能使用一次提交動作插入所有資料；而如果使用Identify類型做主鍵，就必須先插入主鍵列所在表的資料，再插入外鍵列所在表的資料。如下面兩段代碼所示。

// 使用GUID作為主鍵類型
using(MyDataContext db = new MyDataContext())
{
    Category c = new Category
    {
        Id = Guid.NewGuid(),
        Name = "分類1"
    };
    Article a = new Article
    {
        Id = Guid.NewGuid(),
        Title = "標題1",
        Body = "內容",
        CategoryId = c.Id    // Category對象的Id已經確定
    };
    db.Categories.InsertOnSubmit(c);
    db.Articles.InsertOnSubmit(a);

    db.SubmitChanges();    // 一次提交，如果出現錯誤自動全部復原
}

// 使用Identity作為主鍵類型
using(MyDataContext db = new MyDataContext())
{
    Category c = new Category    // 由於才用Identity類型作為主鍵，所以無需也不能明確指定主索引值
    {
        Name = "分類2"
    };
    db.Categories.InsertOnSubmit(c);
    db.SubmitChanges();    // 提交後才能得到確定的ID值

    Article a = new Article
    {
        Title = "標題又來了",
        Body = "沒有內容",
        CategoryId = c.Id
    };
    db.Articles.InsertOnSubmit(a);
    db.SubmitChanges(a);    // 第二個提交，如果出錯，分類c也會留在資料庫中
}

複製代碼

正如注釋中所述，當發生錯誤時，一次提交可以簡單乾淨地復原；但多次提交，就得採取一些手段了。

Identify優於GUID的方面

首先，Identify根本上說是一個int，只佔4位元組；而GUID要佔16位元組。這當然不算什麼，可以忽略。

其次，要知道，主鍵就是一個簇索引（叢集索引），這意味著資料在磁碟上的物理排列順序是和主鍵順序一樣的。這就存在一個問題，每次產生的GUID並不是按照時間順序從小到大的，換句話說，第二次產生的GUID可能比第一次小，而第三次可能又比第二次小。這就導致每次插入一行資料時，都要對錶中整行整行的資料進行排序。而Identify類型的欄位，可以明確保障後產生的值比之前產生的值都大，因此新插入的資料會簡單地追加在表的尾部。所以，對於頻繁插入新資料的表來說，Identify主鍵的效能要好一些。（注意，本條純屬老劉推測，沒有進行過測試。）

最後，Identify主鍵更便於人類閱讀。嗯……給大家各情境吧。在公司，我沒有查看生產環境資料庫的許可權，所以當客戶提交來bug之後，我會朝我老闆喊：幫我把伺服器上ID是1234的使用者的資料取出來我看看~~  想想吧，如果採用了GUID主鍵，我該怎麼喊？

-----

注，寫到這裡，就完了。但我發現好像有些傾向於Identify主鍵。希望大家不要有這樣的偏見，好好看看《ADO.NET 2.0進階編程》，考慮考慮。歡迎大家在這裡探討。

 

轉自：http://www.cnblogs.com/AndersLiu/archive/2008/07/03/primer-key-guid-vs-identify-int.html