生成GUID

我正在考慮在使用SQL Server的.net應用程序中使用GUID。我應該編寫一個存儲過程，在每個輸入的記錄上生成GUID，或者我應該直接從應用程序生成它。生成GUID

理由問這個問題（如果我錯了糾正我在這個）：

我（AS /預）廟：

當從數據庫中生成的GUID，你可以假設DB記住以前生成的GUID作爲應用程序記住它很困難。

2010-07-05 Chaitanya

爲什麼記住以前的GUID是重要還是必需的？ – 2010-07-05 09:58:11

如果您使用GUID作爲數據庫中的主鍵，請注意其優缺點;） http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus- guids.html – Tony 2010-07-05 10:52:21

SQL Server創建了內置的GUID。不需要爲此編寫單獨的存儲過程。

您可以使用

NEWID()

NEWSEQUENTIALID()

兩個程序之間的主要區別將是連續GUID應該使用，如果它是一個主要的集羣鍵。

我不確定爲什麼您希望數據庫引擎記住以前生成的GUID。

2010-07-05 09:44:39

不，你的假設是錯誤的：數據庫不會記住任何事情 - 所以從這個角度來看沒有任何好處。

如果您正在使用GUID在SQL Server的主鍵/聚集鍵，這是一個壞主意，開始（見here，here或here爲什麼是這種情況），你應該至少使用newsequentialid()作爲該列的默認約束。

CREATE TABLE YourTable(ColumnA uniqueidentifier DEFAULT NEWSEQUENTIALID())

這樣一來，該數據庫將產生僞連續GUID對您的PK，從而將使使用GUID作爲PK/CK至少可以忍受....

如果你」的負面影響不要使用GUID作爲主鍵，那麼我真的沒有看到在服務器上創建GUID的好處。

2010-07-05 09:43:00

我能想到一些有效的商業案例，使用（順序）GUID將是一個不錯的選擇。 AMOF，如果我們幾年前知道我們現在知道的，我們很可能已經實施了它們併爲我們節省了很多麻煩（和金錢），試圖與我們的分支機構來回交換數據。 – 2010-07-05 10:03:04

@lieven：似乎你在談論複製 - 這可能是你真正需要它們的唯一有效案例。讓他們成爲你的PK，但如果可能的話，使用別的東西作爲你的羣集鍵！ – 2010-07-05 10:16:30

@marc_s謝謝。但是如果服務器重新啓動呢？！我知道你會失去你的順序。我錯了嗎？ – 2014-09-30 07:09:15

我的首選是在應用程序中創建GUID而不是db。

簡化插入後的行檢索。
更容易的域/業務層單元測試。
更快。至少對於實體框架。 http://blogs.msdn.com/b/adonet/archive/2010/06/28/performance-impact-of-server-side-generated-guids-in-ef.aspx

2010-07-05 09:48:24

-1

RFC4122 1：«不要認爲UUID很難猜測;例如，它們不應該被用作安全功能（僅僅擁有授權訪問權的標識符）。一個可預測的隨機數字來源將加劇這種情況»。

在簡單的任務增量uint64更好。

不使用GUID！如果需要安全。

2013-01-02 19:17:29 STTR

回答