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

Поэтому на моем простом обучающем веб-сайте я использую встроенную систему аутентификации ASP.NET.

Теперь я добавляю пользовательскую таблицу для сохранения таких вещей, как его zip, DOB и т. Д. Мой вопрос:

  1. В новой таблице, если ключом должно быть имя пользователя (строка) или идентификатор пользователя, который представляет собой тот номер GUID, который они используют в asp_ tables.
  2. Если лучше всего использовать это уродливое руководство, кто-нибудь знает, как его получить? кажется, он не так легко доступен, как имя ( System.Web.HttpContext.Current.User.Identity.Name)
  3. Если вы предлагаете мне не использовать ни поля (ни поля guid, ни поля userName, предоставляемые аутентификацией ASP.NET), то как мне это сделать с аутентификацией ASP.NET? Один из вариантов, который мне нравится, - использовать адрес электронной почты пользователя в качестве входа в систему, но как заставить систему проверки подлинности ASP.NET использовать адрес электронной почты вместо имени пользователя? (или там нечего делать, это просто я решаю, что «знаю», что userName - это на самом деле адрес электронной почты?

Пожалуйста, обрати внимание:

  • Я не спрашиваю, как получить GUID в .NET, я просто имею в виду столбец userID в asp_ tablesas guid.
  • Имя пользователя уникально при проверке подлинности ASP.NET.

Ответов (12)

Решение

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

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

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

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

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

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

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

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

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

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

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

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

Dim guidProduct As Guid = Guid.NewGuid()

или

Guid guidProduct = Guid.NewGuid();

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

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

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

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

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

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

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

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

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

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

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

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

должно быть

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

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

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

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

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

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