今天下午與我的同事們討論了GUIDS與IDENTITY字段作爲主鍵的優點。從大數據背景來看，我本能地選擇了IDENTITY，但他們更偏向於網絡，他們更喜歡GUIDS。SPA中表格的GUID或ID
大部分的利弊是有據可查的，在這裏巧妙地概括：
http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html
但我的同事做了點我不能回答，既不能谷歌，我想這是一個有趣的問題。在單頁面應用程序樣式系統中，爲了減少服務器往返行程，JavaScript模型（即Breeze JS）通常用於在提交之前臨時保存許多可能的數據庫更改。這增加了由於同時插入另一個表而導致表的IDENTITY字段增加的機會。當然，當你嘗試提交時會造成混亂。
在這種情況下，特別是考慮到SPA一般不會在數據庫級別存在性能瓶頸，那麼通常使用GUID更合理些嗎？或者我們是否誇大了堆疊多個更改提交的潛在問題？
正如傑伊所說，不用擔心商店生成的Ids的競爭狀況。 Breeze使用臨時密鑰，將其解析爲數據庫層上的永久密鑰。不用擔心。
但我通常更喜歡Guids，原因很不同，受到作爲客戶端開發人員面對的問題的影響，他對服務器端效率的興趣不大。
Guids在分佈式應用程序（如Breeze應用程序）中的最佳原因是脫機方案更容易支持。臨時密鑰（Breeze處理得相當好）在實體導出和導入時不能很好地保存下來......就像在客戶端存儲中存儲未保存的新實體時一樣（例如，瀏覽器存儲）。即使你不下線，這種模式也很有用;當用戶在工作流程中移動時，我經常在本地隱藏未保存的工作...以防萬一他/她偶然關閉瀏覽器。
說實話，Guids確實對你服務器端的人來說並不是什麼大問題。您可以利用受時間影響的Guid（例如GuidComb）打破碎片問題。隨着更快的硬件和更好的數據庫，存儲和索引性能問題正在減少。關於唯一需要查看代理鍵的人是開發人員;我們付出了痛苦。
我寫了大量的演示，毫無疑問，使用整數身份密鑰使作者和讀者的工作更容易。我不認爲演示提供了良好的指導。
實際上，我使用混合的關鍵數據類型，即使它們不是身份。我的靜態引用實體（lookup：status，US States等）和很少更改的實體（產品目錄中的產品）通常是整數鍵。他們更容易閱讀和設置（並且更容易存儲）。客戶經常創建的實體（例如，訂單）使用Guid。
沒有人回答。你的里程會有所不同。在這裏插入陳詞濫調。
不知道我是否正在回答您的問題，但如果您在Breeze中使用標識列，則Breeze會在保存之前自動爲任何新實體生成臨時標識值。在服務器上一旦生成「真實」ID，Breeze就會將臨時ID映射到客戶端，並修復客戶端ID以匹配新的「真實」ID。在保存期間，身份值生成完全由數據庫處理，因此在使用身份列時意外重新使用ID並導致提交失敗並不存在實際問題。工件是所有「添加」記錄（涉及身份或服務器生成的密鑰的那些記錄）的ID將在保存成功完成時自動更改。
這就是說，如果你使用Guids，那麼這些都不是必須的。不需要修復，客戶端ID不會因保存而改變。 Guid傾向於有點大，並且'可能'顯示比標識列更少的局部性（因此可能導致更慢的節省）。即它們通常分散在數據庫中而不是附加到現有的表中。 （Sequential Guids部分彌補了這一點）。
這兩種技術都是可行的，並有支持者。儘管如此，我個人更喜歡Guids。我喜歡簡單。