我應該使用用戶名還是用戶的ID引用ASP.NET中的已驗證用戶

Question

因此，在我簡單的學習網站中，我使用內置的ASP.NET身份驗證系統。

我現在增加一個用戶表保存的東西像他的拉鍊，出生日期等。我的問題是：

1. 在新表中，應重點是用戶名（字符串）或用戶ID，這是他們在asp_ tables中使用的GUID查找號碼。
2. 如果最好的做法是使用那個醜陋的指導，有人知道如何得到它嗎？它似乎不像名稱一樣容易訪問（System.Web.HttpContext.Current.User.Identity.Name）
3. 如果您建議我既不使用（不是由ASP.NET身份驗證提供的guid或userName字段），那麼如何使用ASP.NET身份驗證執行此操作？我喜歡的一種選擇是使用用戶的電子郵件地址作爲登錄名，但是如何讓ASP.NET身份驗證系統使用電子郵件地址而不是用戶名？ （或沒有什麼在那裏做，那只是我的決定我「知道」的userName實際上是一個電子郵件地址

請注意：

• 我不問如何獲得一個GUID .NET，我只是指的是用戶ID列在asp_ tables作爲GUID。
• 用戶名是在ASP.NET驗證獨特。

Answer 1

我會建議使用的用戶名作爲表的主鍵，如果用戶名將會是唯一的，有幾個很好的理由這樣做：

1. 的主鍵會一個聚集索引，從而通過他們的用戶名搜索用戶詳細信息將非常快速。
2. 它將停止重複的用戶名出現
3. 你不必擔心使用的信息兩種不同的peices（用戶名或GUID）
4. 這將使因爲不必查找兩個位代碼的編寫更容易的信息。

Answer 2

您應該使用一些獨特的ID，無論是GUID你提到或一些其他汽車生成器ated key。但是，該數字對於用戶而言永遠不可見。

這樣做的一個巨大好處是您的所有代碼都可以在用戶標識上工作，但用戶的名稱並非真正與其綁定。然後，用戶可以更改他們的名字（我發現它在網站上很有用）。如果您使用電子郵件地址作爲用戶的登錄信息，這對用戶非常方便（如果用戶的普通用戶ID很流行，他們不必記住20個ID），這一點尤其有用。

Answer 3

我同意邁克斯通。我還建議只有在您要跟蹤大量數據的情況下使用GUID。否則，一個簡單的自動遞增整數（Id）列就足夠了。

如果你確實需要的GUID，.NET是夠可愛，你可以得到一個由簡單的...

Dim guidProduct As Guid = Guid.NewGuid() 

或

Guid guidProduct = Guid.NewGuid(); 

Answer 4

您應該使用的用戶名。 它是MembershipUser的ProviderUserKey屬性。

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString()); 

Answer 5

我會使用用戶標識。如果你想使用用戶名，你將會使「更改用戶名」功能非常昂貴。

Answer 6

如果你打算使用LinqToSql進行開發，我會建議使用Int作爲主鍵。當我使用非Int字段構建關係時，即使nvarchar（x）字段有約束使其成爲唯一字段，我也遇到了很多問題。

我不確定這是LinqToSql中的一個已知錯誤還是什麼，但是我在當前項目中遇到了問題，我不得不在多個表上換出PK和FK。

Answer 7

我同意邁克斯通也。我的公司最近爲外部客戶實現了一個新的用戶表（與通過LDAP進行身份驗證的內部用戶相反）。對於外部用戶，我們選擇將GUID作爲主鍵存儲，並將用戶名作爲varchar在用戶名字段中以唯一約束存儲。另外，如果您要存儲密碼字段，我強烈建議將密碼存儲爲數據庫中的醃製散列二進制文件。這樣，如果有人要破解你的數據庫，他們將無法訪問你的客戶的密碼。

Answer 8

我會使用一個自動遞增的數字通常是一個int。

你想保持密鑰的大小盡可能小。這使您的索引變得更小，並且也有利於任何外鍵。此外，您並未將數據設計與外部用戶數據緊密耦合（這也適用於aspnet GUID）。

通常，GUID不會成爲主鍵，因爲它們很大，並且插入可能發生在表中的任何數據頁上，而不是在最後一個數據頁上。這個主要的例外是如果你正在運行多重複制的數據庫。在這種情況下GUID對鍵很有用，但我猜你只有一個數據庫，所以這不是問題。

Answer 9

我Palmsey， 同意雖然有似乎是在他的代碼一點點錯誤：

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name)).ProviderUserKey.ToString()); 

應該

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString()); 

Answer 10

我會說使用用戶標識，以便用戶名仍然可以改變而不會影響主鍵。我還會將用戶名列設置爲唯一以停止重複的用戶名。

如果您主要搜索的是用戶名而不是用戶名，請將用戶名設置爲聚簇索引，並將主鍵設置爲非聚簇。這會在搜索用戶名時爲您提供最快的訪問權限，但是您將主要搜索UserIds，然後將其作爲聚集索引。

編輯：這也將更適合當前的ASP.Net會員表，因爲他們也使用用戶ID作爲主鍵。

Answer 11

我會在我的代碼中使用guid，並且已經提到了一個電子郵件地址作爲用戶名。畢竟，它對用戶來說已經是獨一無二的，令人難忘。也許甚至溝渠guid（訴辯論）。

有人提到在GUID上使用聚簇索引（如果在代碼中使用該聚簇索引）。我會避免這種情況，特別是如果INSERT高;每次插入記錄時索引都會重建。儘管由於只添加新記錄，聚簇索引在自動增量ID上運行良好。

Answer 12

這是舊的，但我只是希望人們誰發現這個要注意幾件事情：當談到訪問用戶記錄

1. 的ASPNET會員數據庫進行了優化。在使用更低的用戶名和applicationid搜索記錄時，將使用sql server中的聚簇索引查找（最佳）。這很有意義，因爲我們只有在用戶首次發送憑證時才提供用戶名。

2. guid userid將給出比int更大的索引大小，但這並不重要，因爲我們通常每次只檢索1個記錄（用戶），並且在碎片方面，讀取次數通常大大超過寫入和編輯到用戶表的次數 - 人們根本不會經常更新該信息。

3. 可以編輯創建aspnet成員資格表的regsql腳本，以便不使用NEWID作爲用戶標識的缺省值，而是可以使用NEWSEQUENTIALID（）來提供更好的性能（我已經對此進行了描述）。

4. 簡介。有人創建一個「新的學習網站」不應該試圖重新發明輪子。我曾經工作的一個網站使用了開箱即用的aspnet會員表（不包括可怕的個人資料系統），用戶表包含近200萬個用戶記錄。即使有如此多的記錄，選擇仍然很快，因爲正如我剛纔所說的那樣，數據庫索引集中在用於更低索引用戶名和應用程序標識以聚集索引查找這些記錄，並且一般來說，如果sql正在執行聚集索引查找找到1條記錄，即使記錄數量巨大，您也不會遇到任何問題，前提是您不要向列中添加列並開始回拉太多數據。

5. 基於系統的實際性能和經驗，擔心這個系統中的GUID是不成熟的優化。如果你的userid有一個int，但是系統由於你的自定義索引設計等而執行次優查詢，系統不能很好地擴展。微軟傢伙在aspnet成員資格數據庫方面做得很好，並且比將userId更改爲int更有效。