Должен ли я использовать имя пользователя или ID пользователя для ссылки на аутентифицированных пользователей в ASP.NET

Вы должны использовать какой-то уникальный ID, либо GUID, который вы упоминаете, либо какой-то другой автоматически сгенерированный ключ. Однако этот номер никогда не должен быть виден пользователю.

Огромным преимуществом этого является то, что весь ваш код может работать с пользователем ID, но имя пользователя на самом деле не привязано к нему. Затем пользователь может изменить свое имя (которое я нашел полезным на сайтах). Это особенно полезно, если вы используете адрес email в качестве логина пользователя... что очень удобно для пользователей (тогда им не нужно помнить 20 IDs, если их общий пользователь ID является популярным).

Вы должны использовать UserID. Это свойство ProviderUserKey из MembershipUser.

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

Я бы предложил использовать имя пользователя в качестве первичного ключа в таблице, если имя пользователя будет уникальным, есть несколько веских причин для этого:

1. Первичным ключом будет кластеризованный индекс, и поэтому поиск сведений о пользователе через его имя пользователя будет очень быстрым.
2. Это остановит появление повторяющихся имен пользователей
3. Вам не нужно беспокоиться об использовании двух различных типов информации (имя пользователя или идентификатор guid)
4. Это значительно упростит написание кода, поскольку не нужно будет искать два бита информации.

Я бы использовал идентификатор пользователя. Если вы хотите использовать имя пользователя, вы собираетесь сделать функцию "change the username" очень дорогой.

Я согласен с Палмси, Хотя, кажется, в его коде есть небольшая ошибка:

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

должно быть

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

Я бы сказал, используйте UserID, чтобы имена пользователей все еще можно было изменить, не затрагивая первичный ключ. Я бы также установил столбец username уникальным, чтобы остановить дублирование имен пользователей.

Если вы в основном будете искать по username, а не по UserID, то сделайте Username кластеризованным индексом и установите первичный ключ некластеризованным. Это даст вам самый быстрый доступ при поиске имен пользователей, однако если вы будете искать в основном UserIds, то оставьте это в качестве кластеризованного индекса.

Edit: это также будет лучше сочетаться с текущими таблицами членства ASP.Net, поскольку они также используют UserID в качестве первичного ключа.

Это старо, но я просто хочу, чтобы люди, которые найдут это, отметили несколько вещей:

1. База данных членства aspnet IS оптимизирована, когда речь заходит о доступе к записям пользователей. Кластеризованный индекс seek (оптимальный) в sql server используется при поиске записи с использованием loweredusername и applicationid. Это имеет большой смысл, поскольку у нас есть только предоставленное имя пользователя, чтобы продолжить, когда пользователь впервые отправляет свои учетные данные.

2. Guid userid даст больший размер индекса, чем int, но это не очень важно, потому что мы часто получаем только 1 запись (пользователя) за один раз, и с точки зрения фрагментации, количество операций чтения обычно значительно превышает количество операций записи и редактирования в таблицу пользователей - люди просто не обновляют эту информацию так часто.

3. скрипт regsql, создающий таблицы членства aspnet, можно отредактировать таким образом, чтобы вместо использования NEWID в качестве идентификатора пользователя по умолчанию он мог использовать NEWSEQUENTIALID(), что обеспечивает лучшую производительность (я профилировал это).

4. Профиль. Тот, кто создает "new learning website", не должен пытаться заново изобрести колесо. Один из веб-сайтов, на котором я работал, использовал готовую версию таблиц членства aspnet (за исключением ужасной профильной системы), а таблица пользователей содержала почти 2 миллиона записей пользователей. Даже при таком большом количестве записей выбор все равно был быстрым, потому что, как я уже говорил, индексы базы данных фокусируются на loweredusername+applicationid для формирования кластеризованного индекса искать эти записи и вообще, если sql делает кластеризованный индекс искать 1 запись, у вас нет никаких проблем, даже с огромным количеством записей, при условии, что вы не добавляете столбцы в таблицы и не начинаете вытягивать слишком много данных.

5. Беспокойство по поводу guid в этой системе, на мой взгляд, основано на фактической производительности и опыте работы системы, является преждевременной оптимизацией. Если у вас есть int для вашего идентификатора пользователя, но система выполняет неоптимальные запросы из-за вашего пользовательского дизайна индекса и т. д. система не будет хорошо масштабироваться. Ребята из Microsoft в целом хорошо поработали с базой данных членства aspnet, и есть много более продуктивных вещей, на которых можно сосредоточиться, чем изменение userId на int.

Я бы использовал автоматическое увеличение числа обычно int.

Вы хотите, чтобы размер ключа был как можно меньше. Это позволяет сохранить ваш индекс небольшим и выгодно использовать любые внешние ключи. Кроме того, вы не слишком плотно связываете дизайн данных с внешними пользовательскими данными (это справедливо и для aspnet GUID).

Обычно GUIDs не делают хороших первичных ключей, так как они большие и вставки могут произойти на потенциально любой странице данных в таблице, а не на последней странице данных. Основное исключение из этого правила-если вы используете реплицированные базы данных mutilple. GUIDs очень полезны для ключей в этом сценарии, но я предполагаю, что у вас есть только одна база данных, так что это не проблема.

Если вы собираетесь использовать LinqToSql для разработки, я бы рекомендовал использовать Int в качестве первичного ключа. У меня было много проблем, когда у меня были отношения, построенные из не-Int полей, даже когда поле nvarchar(x) имело ограничения, чтобы сделать его уникальным полем.

Я не уверен, что это известная ошибка в LinqToSql или что, но у меня были проблемы с этим в текущем проекте, и мне пришлось поменять местами PKs и FKs на нескольких таблицах.

Я согласен с Майком Стоуном. Я бы также предложил использовать только GUID в том случае, если вы собираетесь отслеживать огромное количество данных. В противном случае достаточно простого автоматического увеличения целого числа (Id) столбца.

Если вам действительно нужен GUID, .NET достаточно хорош, чтобы вы могли получить его простым способом...

Dim guidProduct As Guid = Guid.NewGuid()

или

Guid guidProduct = Guid.NewGuid();

Я тоже согласен с Майком Стоуном. Моя компания недавно внедрила новую таблицу пользователей для внешних клиентов (в отличие от внутренних пользователей, которые аутентифицируются через LDAP). Для внешних пользователей мы решили сохранить GUID в качестве первичного ключа и сохранить имя пользователя как varchar с уникальными ограничениями на поле имени пользователя.

Кроме того, если вы собираетесь хранить поле пароля, я настоятельно рекомендую хранить пароль в виде соленого, хэшированного двоичного файла в базе данных. Таким образом, если кто-то взломает вашу базу данных, у него не будет доступа к паролям ваших клиентов.

Я бы использовал guid в своем коде и, как уже упоминалось, адрес email в качестве имени пользователя. Это, в конце концов, уже уникальный и запоминающийся для пользователя. Может быть, даже выбросить guid (v. спорный).

Кто-то упомянул использование кластеризованного индекса на GUID, если это используется в вашем коде. Я бы избегал этого, особенно если INSERTs являются высокими; индекс будет перестраиваться каждый раз, когда вы INSERT записываете. Кластеризованные индексы хорошо работают при автоматическом инкременте IDs, хотя бы потому, что новые записи добавляются только.