Связь между таблицами поставщиков членства ASPNET и пользовательскими таблицами членства - PullRequest
Новая
       26

Связь между таблицами поставщиков членства ASPNET и пользовательскими таблицами членства

3 голосов
/ 02 декабря 2009

Некоторое время назад я проверил пример провайдера нестандартного профиля, и я сейчас вернемся к нему.

В моей базе данных есть все таблицы dbo.aspnet_ *, созданные при запуске регистрации в aspnet Мастер. В этих таблицах у меня есть aspnet_Profile, который имеет ограничение FK, указывающее на aspnet_Users.

У меня также есть две таблицы в MyDB: первая, dbo.ProfileData, имеет ограничение внешнего ключа указывая на dbo.Profile.

Я хочу понять, как таблицы в MyDB связаны с те, в dbo.aspnet_ *. Не должно быть ограничения внешнего ключа (или какой-то отношения) между таблицами профиля в MyDB и таблицами aspnet? Некоторое обсуждение того, как мои пользовательские таблицы соотносятся с теми, которые предоставляет aspnet, было бы замечательно.

Заранее спасибо.

1 Ответ

1 голос
/ 02 декабря 2009

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

  • FK от dbo.aspnet_User.UserID до dbo.Profile.UserID, затем определите уникальный ключ для dbo.Profile.UserID (если вы не используете его в качестве столбца PK для dbo.Profile)

  • FK от dbo.aspnet_Profile.ProfileID до dbo.Profile.ProfileID

dbo.aspnet_User логически 1 - 1 с dbo.aspnet_Profile, поэтому не имеет значения, какой подход вы используете, поскольку вы все равно получите ту же целостность отношений.

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

EDIT

aspnet_Profile - это стандартная таблица - стандарт SqlProfileProvider хранит данные профиля пользователя в виде сериализованного пакета свойств в aspnet_Profile, поэтому также не существует отдельной таблицы aspnet_ProfileData.

Этот подход позволяет легко настраивать схему профиля для различных приложений, не требуя каких-либо изменений в базовой базе данных, и является наиболее оптимальным решением для такой среды, как .NET. Недостатком является то, что SQL Server вообще не имеет легкого доступа к этим данным, поэтому намного сложнее индексировать, обновлять и запрашивать данные профиля пользователя с использованием T-SQL и логики на основе множеств.

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

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

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

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

...