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

Question

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

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

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

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

Заранее благодарю.

Answer 1

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

• 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, так что на самом деле не имеет значения, какой подход вы используете, поскольку вы все равно получите ту же реляционную целостность.

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

Редактировать

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

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

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

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

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

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