Свяжите пользователей и роли, добавленные в таблицы базы данных SQL ASPNET, с существующей информацией о пользователе.

UserKey, называемый UserId в таблицах членства ASPnet, является GUID, который идентифицирует пользователя. Вы можете добавить столбец UserKey в свою таблицу Users, а затем начать делать такие опасные вещи, как:

select *
  from Users as U inner join
    aspnet_Users as aU on aU.UserId = U.UserKey inner join
    aspnet_Membership as aM on aM.UserId = aU.UserId
  where U.UserId = @UserId

Microsoft (или я) не предоставляет никаких гарантий, явных или подразумеваемых, если вы хотите возиться непосредственно с их таблицами.

У нас была похожая ситуация в проекте, над которым я работал пару лет назад. В итоге мы сохранили первичный ключ связанной записи пользователя из внешней пользовательской таблицы в виде Свойство профиля модели членства ASPNET.

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

Первоначальное заполнение этого свойства профиля было выполнено с помощью утилиты, которую мы написали специально для этой задачи с использованием объектов ASPNET Membership Profile, и было упрощено благодаря тому факту, что и в нашей настройке членства, и во внешней таблице хранится адрес электронной почты пользователя, что делает его ключом для задача на один раз.

Недостатком этого подхода является то, что таблица ASPNET Membership Profile в значительной степени НЕ денормализована (или действительно нормализована, если на то пошло). Он хранит свойства профиля либо в виде данных xml, либо в виде сериализованного двоичного файла. В более старых версиях он был сериализован с именами свойств, хранящимися как имена и позиции символов в строке с одним значением, содержащей все значения. Это затрудняет (если не делает непрактичным) написание запросов, объединений и т. д. с точки зрения вашей внешней таблицы.

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

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