我正在用SqlServer和Linq to Sql啓動新項目。 對於表中的代理鍵，哪種數據類型會更好：identity或uniqueidentifier？Linq to SQL的最佳主鍵數據類型
據我所知，identity是插入時自動生成的，而uniqueidentifier應該在代碼（GUID）中生成。
是否有任何顯着的性能差異？ 例如插入後必須讀取identity值，因此插入後會有額外的數據庫跳閘。
編輯：
我發現了非常詳細的答案另一個問題：Tables with no primary keys。閱讀選定的答案。
編輯2：
有關代理鍵對於答案：我喜歡比自然鍵更加代理鍵。該決定已經完成，因此請不要建議重新考慮數據庫設計。另外，請不要討論自然和代理鍵的優缺點。
我使用身份和int或bigint取決於預期的表大小。我期望LINQ執行結合插入和鍵讀取的單個查詢。
uniqueidentifier也可以自動插入，通過將數據庫中的默認值設置爲NEWID()。
任何一個都可以。這取決於你的設計。當你需要在客戶端創建ID時，UNIQUEIDENTIFIER可以工作，當你建立一個需要在客戶端發送到數據庫之前添加/刪除/修改的對象列表時，它有時會很好。如果您必須合併在不同系統上創建的數據，那也會更好。
INTs較小，所以它們可能會更快，並且當您使用數據調試某些內容時它們更容易使用，因爲它們更易於討論。
總之，這裏沒有「最好」的答案。這是一個設計決定。
我不認爲根據您使用LINQ到SQL的事實來選擇表的主鍵是一個不錯的主意。在我看來，將主鍵用於其預期目的會更好 - 通過唯一標識特定行來確保數據完整性。整數或GUID PK不會保護您在表中存在重複的行（當然，除了自動生成的列）。然後，又一次激烈的關於pro和con的自動生成密鑰的爭論:)
我同意這裏的評論，您應該獨立於您的數據訪問方法設計您的db結構。無論是LINQ2SQL還是ADO.NET或NHibernate，無論您的PK是自動增量身份還是GUID，您都會得到同樣的好處/問題。
我實際上可以認爲只有一個目的是使用GUID來支持INT作爲PK - 在具有多個數據庫的高度分佈式應用程序中，數據需要與主服務器同步等。即使這樣，您也可以使用IDENTITY增量，例如一個數據庫服務器的IDENTITY（1,2），另一個數據庫的IDENTITY（2,2）等[當然只適用於固定數量的DB服務器。]
與GUID的主要「問題」是它需要更多的空間（16字節相比4/8），不僅作爲PK，而且作爲該表中的任何索引的一部分，因爲每個索引存儲PK隱含的價值。比較16個字節也會變得更慢（多少？你應該測量它，這取決於）
此外，由於GUID是隨機的，插入行時可以得到很多頁分割（雖然我相信有一個新的函數在SQL Server 2005或2008中生成連續的GUID）放入一個表中。在有大量插入的環境中，這本身可能會相當昂貴。
好的，我剛剛寫了一個blog about this。我爲其他人轉貼以下優惠。
的基本要點似乎是在ado.net博客，說明實體框架提出的意見是獲得主要開發商的時間Visual Studio 2010和點網的唯一的事4.
我們已經知道這
我的回答是 - DUH。我們都知道這一點。微軟在PDC 2007上公開表示，對於SQL Server來說，LINQ to SQL是一個短期版本，因爲沒有其他的LINQ故事給SQL Server。它只適用於SQL Server。你不能寫一個LINQ to SQL提供程序 - 它沒有模型。這是一種一次性技術，不可擴展。
實體框架=提供商
實體框架是Microsoft提供的唯一的方式來建立一個LINQ提供程序。實體框架已經證明是非常矛盾的，但我認爲這部分是由於LINQ to SQL在今天具有更好的程序員體驗。實體框架將捕獲並超越LINQ to SQL，因爲它是Microsoft未來的ORM/Mapping工具。
我認爲微軟在像我們這樣的第三方供應商，IBM，甲骨文等公司有鉅額的投資。如果他們希望第三方開發人員和數據庫支持LINQ，他們必須有一個模型來寫信。實體框架就是這個答案。
去年我看到了這一點，他們將VS 2008與LINQ to SQL相比，而不是EF。他們決不應該發佈一個有太多重疊的封閉實現。我知道他們想要一個關係數據庫的故事，但我認爲他們說錯了。現在有很多非常困惑的開發者向我們詢問我們的LINQ to SQL提供者。沒有一個，因爲你不能寫一個。
是的，SQL 2005中的新函數是NEWSEQUENTIALID（），它緩解了這個問題。但當乘以百萬（？）行時，有16個字節是很多... – 2008-10-31 12:46:13