ASP.NET Поставщик членства: определение внешнего ключа для aspnet_Users.Имя пользователя

#asp.net-membership #foreign-keys #sql-server-express #uniqueidentifier

#asp.net-членство #внешние ключи #sql-сервер-экспресс #уникальный идентификатор

Вопрос:

Я хотел бы настроить внешний ключ для таблицы членства по умолчанию, но при попытке ее определения я получаю сообщение об ошибке. Я использую таблицу aspnet_Users по умолчанию, а также свою собственную таблицу Posts. Я пытаюсь настроить таблицы следующим образом:

aspnet_Users ( Пользователи сети )

Идентификатор пользователя (PK) уникальный идентификатор
Имя пользователя nvarchar(256)

Публикации

postID (PK) int
Имя пользователя (FK -> aspnet_Users.Имя пользователя) nvarchar(256)

Однако, когда я пытаюсь настроить это с помощью конструктора VS 2010, он выдает следующую ошибку:

 The columns in table 'aspnet_Users' do not match an existing primary key
or unique constraint.

Это не работает, потому aspnet_Users.UserName что не является частью PK for aspnet_Users ? Я попытался изменить таблицу, чтобы включить ее как часть PK (я думаю, это делает ее составным ключом?) но это говорит мне сначала удалить отношения, прежде чем я смогу это сделать. Поскольку я не знаю, какие отношения определяют таблицы членства по умолчанию, я бы предпочел узнать больше, прежде чем идти по этому пути.

Ответ №1:

Сообщение об ошибке полностью описывает ситуацию — вы пытаетесь использовать неключевое поле внутри ограничения внешнего ключа. Вы предлагаете попытаться создать составной ключ, чтобы обойти эту проблему, что сработало бы, но почему бы вам просто не использовать существующий первичный ключ?

Поле userId является уникальным идентификатором PK, поэтому оно уже настроено для использования в FK. И вы бы использовали нормализацию, так что вместо хранения (до) 256 байт на имя пользователя в каждой строке вы бы сохраняли только uniqueidentifier (16 байт).

1. Я забыл ответить на свой собственный вопрос, поскольку задал его довольно давно. Вместо самостоятельного ответа я приму ваш answewr, поскольку он правильный. Моя первоначальная проблема возникла из-за идеи использования uniqueidentifier в URL-адресах и любых возможных проблем с производительностью и удобочитаемостью, которые могут возникнуть из-за этого. Я привык использовать целые числа в качестве PK для передачи, поэтому я этого не совсем понимал, и многие мои опасения были основаны на неправильных представлениях.

Ответ №2:

Я думаю, вам также нужно объединить его с applicationId. Идентификатор пользователя не является уникальным, за исключением случаев, когда он объединен с идентификатором приложения.