Лучший подход к проектированию базы данных для объединения сложных данных в таблицы членства ASP.Net

Question

Я хочу использовать слегка модифицированный поставщик членства ASP.Net для обработки стандартного создания учетной записи пользователя / аутентификации / и т. Д. На веб-сайте.У нас есть достаточное количество устаревших данных, которые мне нужно перенести, чтобы обеспечить непрерывность сохраненной информации наших существующих пользователей (таких как история заказов, список пожеланий и т. Д.).[ПРИМЕЧАНИЕ. В любом случае мы должны выполнить миграцию, поэтому это не причина, по которой мы переносим данные]

Мне интересно, каков разумный подход для объединения этих дополнительных данных в таблицы членства asp.net.Есть два уникальных ключа, которые я мог бы использовать в пользовательской таблице - UserId или электронная почта - которые мы будем использовать в качестве суррогата имени пользователя.

Мой вопрос заключается в том, какой шаблон доступа лучше (и, следовательно, внешний ключ).) использовать в других местах моих таблиц для хранения заказов, списков пожеланий и т. д.?

В HttpContext доступен объект User, который содержит «Имя пользователя», наш адрес электронной почты, но не имеет Guid для userId.

Я вижу 3 варианта:

1. Я бы хотел просто использовать уникальный идентификатор пользователя идентификатора для эффективности доступа по длинному адресу электронной почты varchar, но он не выглядит легкодоступным без дополнительных обращений к базе данных, чтобы получить его по электронной почте или через логин.Есть ли какой-то способ получить UserId, чтобы я мог сделать его внешним ключом для разных таблиц?
2. Я могу передать адрес электронной почты (имя пользователя) в качестве входного параметра, присоединиться к userId, где email address = @emailAddress,и используйте userId в качестве внешнего ключа для других таблиц.

Недопустимо

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

Любые мысли о лучшем методе с точки зрения БД или из приложенияперспективы эффективности?

Answer 1

Вы можете получить UserId:

MembershipUser myObject = Membership.GetUser();
        string UserID = myObject.ProviderUserKey.ToString();

или, может быть (пожалуйста, проверьте это)

  string userId = Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString();