我應該使用用戶名或用戶ID來引用ASP.NET中經過身份驗證的用戶

Question

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

我現在添加一個用戶表來保存像他的拉鏈，DOB等東西。我的問題是：

1. 在新表中，鍵應該是用戶名（字符串）還是用戶ID，它是在asp_ tables使用的GUID查找號碼。
2. 如果最好的做法是使用那個丑陋的guid，有誰知道如何獲得它？ 它似乎不像名稱那樣容易訪問（ System.Web.HttpContext.Current.User.Identity.Name ）
3. 如果您建議我不使用（不是ASP.NET身份驗證提供的guid和userName字段），那么如何使用ASP.NET身份驗證呢？ 我喜歡的一個選項是使用用戶的電子郵件地址作為登錄，但是如何使ASP.NET身份驗證系統使用電子郵件地址而不是用戶名？ （或者那里沒什么可做的，只是我決定我“知道”userName實際上是一個電子郵件地址？

請注意：

• 我不是在詢問如何在.NET中獲取GUID，我只是將asp_ tables的userID列稱為guid。
• 用戶名在ASP.NET身份驗證中是唯一的。

Answer 1

您應該使用一些唯一的ID，您提到的GUID或其他一些自動生成的密鑰。 但是，該號碼永遠不會對用戶可見。

這樣做的一個巨大好處是，您的所有代碼都可以處理用戶ID，但用戶的名稱並不真正依賴於它。 然后，用戶可以更改他們的名字（我發現在網站上有用）。 如果您使用電子郵件地址作為用戶的登錄信息，這將非常有用...這對用戶來說非常方便（那么他們不必記住20個ID，以防他們的普通用戶ID是一個流行的用戶ID）。

Answer 2

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

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

Answer 3

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

1. 主鍵將是聚簇索引，因此通過用戶名搜索用戶詳細信息將非常快。
2. 它將阻止重復的用戶名出現
3. 您不必擔心使用兩種不同的信息（用戶名或guid）
4. 它將使編寫代碼變得更加容易，因為不必查找兩位信息。

Answer 4

我會使用userid。 如果您想使用用戶名，您將使“更改用戶名”功能非常昂貴。

Answer 5

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

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

應該

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

Answer 6

我會說使用UserID所以仍然可以更改用戶名而不影響主鍵。 我還要將用戶名列設置為唯一以停止重復的用戶名。

如果您主要搜索用戶名而不是UserID，則將Username設置為聚簇索引，並將主鍵設置為非群集。 這將在搜索用戶名時為您提供最快的訪問權限，但是如果您將主要搜索UserIds，則將其保留為聚簇索引。

編輯：這也適用於當前的ASP.Net成員資格表，因為它們也使用UserID作為主鍵。

Answer 7

這已經很久了，但我只是想讓發現這一點的人注意到一些事情：

1. 在訪問用戶記錄時，aspnet成員資格數據庫已經過優化。 當使用lowerusername和applicationid搜索記錄時，將使用sql server中的聚簇索引seek（最佳）。 這很有意義，因為我們只有用戶首次發送憑據時才會提供用戶名。

2. guid用戶標識將提供比int更大的索引大小，但這並不重要，因為我們通常一次只檢索1條記錄（用戶），而在碎片方面，讀取次數通常大大超過寫入和編輯的次數對於用戶表 - 人們根本不會經常更新該信息。

3. 可以編輯創建aspnet成員資格表的regsql腳本，以便不使用NEWID作為userid的默認值，而是可以使用NEWSEQUENTIALID（）來提供更好的性能（我已經對此進行了分析）。

4. 輪廓。 創建“新學習網站”的人不應該試圖重新發明輪子。 我工作過的其中一個網站使用了aspnet成員資格表的開箱即用版本（不包括可怕的個人資料系統），用戶表包含近200萬個用戶記錄。 即使有如此多的記錄，選擇仍然很快，因為，正如我開始所說，數據庫索引專注於lowerusername + applicationid peform聚集索引尋找這些記錄，一般來說，如果sql正在進行聚簇索引搜索找到1條記錄，你沒有任何問題，即使有大量的記錄，只要你沒有在表中添加列並開始撤回過多的數據。

5. 基於系統的實際性能和經驗，對我來說擔心這個系統中的guid是過早的優化。 如果您的userid有一個int，但由於您的自定義索引設計等原因系統執行次優查詢，系統將無法很好地擴展。 微軟的人員在aspnet成員資格數據庫方面做得非常出色，而且要將重點放在比將userId更改為int更多的事情上。

Answer 8

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

您希望保持密鑰的大小盡可能小。 這使您的索引保持較小並且也可以使任何外鍵受益。 另外，您沒有將數據設計與外部用戶數據緊密耦合（這也適用於aspnet GUID）。

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

Answer 9

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

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

Answer 10

我同意Mike Stone的觀點。 如果您要跟蹤大量數據，我還建議僅使用GUID。 否則，一個簡單的自動遞增整數（Id）列就足夠了。

如果你確實需要GUID，.NET很可愛，你可以通過一個簡單的...

Dim guidProduct As Guid = Guid.NewGuid()

要么

Guid guidProduct = Guid.NewGuid();

Answer 11

我也同意邁克斯通。 我公司最近為外部客戶端實現了一個新的用戶表（而不是通過LDAP進行身份驗證的內部用戶）。 對於外部用戶，我們選擇將GUID存儲為主鍵，並將用戶名作為varchar存儲在用戶名字段的唯一約束中。

此外，如果您要存儲密碼字段，我強烈建議將密碼存儲為數據庫中的鹽漬哈希二進制文件。 這樣，如果有人要破解您的數據庫，他們就無法訪問您客戶的密碼。

Answer 12

我會在我的代碼中使用guid，並且已經提到了一個電子郵件地址作為用戶名。 畢竟，它已經為用戶帶來了獨特和難忘的體驗。 也許甚至放棄了guid（v。辯論）。

有人提到在GUID上使用聚簇索引（如果在您的代碼中使用它）。 我會避免這種情況，特別是如果INSERT很高; 每次插入記錄時都會重建索引。 群集索引在自動增量ID上運行良好，因為僅添加了新記錄。