我注意到asp_membership使用uniqueidentifier，對我來說，這看起來像是浪費空間，因爲我想不出有什麼特別的理由不能用身份代替它。uniqueidentifier vs identity
但是，SQL Server不讓我將其更改爲int。它表示「連接的數據庫服務器不支持從uniqueidentifier到int的轉換」。谷歌搜索後，似乎我將不得不打破所有的關係等，然後手動刪除列並重新添加爲int。你們知道更好的方法嗎？
我不認爲我會處理多個數據庫，所以uniqueidentifier似乎不需要我。你同意嗎？
請注意：我正在開始一個新的Web應用程序。你是否仍然認爲解決這個問題會很困難？
此外，請注意，我的任何主鍵都不會成爲我網址的一部分。
我的建議是保持獨立。你說得對，你需要去做很多工作（如你所描述的）才能擺脫它。爲什麼？爲什麼要亂用一些正常的東西？爲了節省數據庫空間？就像現在存儲的便宜和硬盤驅動器或存儲陣列的平均大小一樣，您所談論的是節省的空間量非常少。
這個想法沒有投資回報。
+1。投資回報率是一種很好的投入方式 – 2009-09-12 05:16:27
如果它沒有損壞... – 2009-09-12 05:21:48
http://www.codinghorror.com/blog/archives/000817.html傑夫的好文章。 – 2009-09-12 05:54:42
Uniqueidentifier和int是非常不同的數據類型。你不能只是把一個guid改成int。您需要刪除所有關係，將數值分配給父表，將數字列添加到所有子表，使用連接來設置子表中的所有值。刪除所有的guid列，使int列成爲主鍵。建立所有的關係。
更不用說更改與數據庫交談的每個應用程序，並且期望該值是一個guid，以便它可以使用整數值。
你正在看很多很少的工作。
是的，你會得到一些性能改善，因爲guids是不連續的，數字會是。但是，除非您看到一些主要的性能問題，否則這實際上並不足以成爲實際進行修改的理由。
至少你會看到幾個星期的工作和測試。在現實中幾個月要確保你抓住每一個可能的變化。
Nit要選擇：如果使用NEWSEQUENTIALID（）而不是NEWID（）來默認主鍵列，則GUID *爲* sequential。 – richardtallent 2009-09-12 08:04:19
確實如此，但不知道他使用的是什麼版本，並不能保證NEWSEQUENTIALID（）可用。你會驚訝有多少人不知道，即使存在。 – mrdenny 2009-09-13 04:02:55
您不能轉換UNIQUEIDENTIFIER列INT - 這裏就是你需要什麼在這種情況下，做的是
當然，由於「用戶名」是主鍵，因此將來自很多地方被引用，你必須在能夠刪除UserId列之前，需要做大量的清理工作。我認爲在這種特殊情況下，我可能會將其保留爲「原樣」 - 嘗試使用UNIQUEIDENTIFIER作爲SQL Server表中的主鍵和集羣鍵的非常不錯的選擇。轉換會在整個ASP.NET表格中造成大量的波紋變化 - 可能只是不值得。
馬克
> UNIQUEIDENTIFIER是一個非常糟糕的選擇 如果您將應用程序出售給多個客戶，並且以後的客戶A購買客戶B，那麼將數據庫與GUID PK合併而非Ints合併會非常容易，因爲缺少重複。 – kevinw 2009-09-12 08:55:57
如果您使用GUID作爲集羣密鑰，那麼您不會賣給多個客戶，因爲您的性能很差..... :-)只是在開玩笑！ :-)同意 - 有些情況下它可能是有道理的。但在這種情況下，您可以輕鬆添加一個「CustomerID」INT來保持兩者分開。總有幾種方法可以做某些事情。但是GUID作爲集羣的關鍵是真的很糟糕。 – 2009-09-12 10:03:03
因爲你可能沒有數百萬的用戶，爲什麼擔心保存每個用戶12個字節...... – 2009-09-12 05:12:10
即使你有幾百萬的用戶，節省12MB（加索引）的。誰在乎！ – 2009-09-12 05:12:59
@Mitch小麥 - 正是我的想法。 – David 2009-09-12 05:14:13