Relation entre les tables de fournisseur d'appartenances et ASPNET Tableaux personnalisés membres

Question

Je suis passé par un exemple personnalisé fournisseur de profil il y a un certain temps et je suis maintenant revisiter.

Ma base de données a toutes les dbo.aspnet_ * tables créées quand je courais l'enregistrement aspnet sorcier. Dans ces tableaux, je aspnet_Profile qui a une contrainte FK pointant vers aspnet_Users.

J'ai aussi deux tables dans MyDB: La première, dbo.ProfileData, a une contrainte de clé étrangère pointant vers dbo.Profile.

Ce que je veux comprendre comment les tableaux se rapportent à MyDB ceux dbo.aspnet_ *. Ne devrait pas être là une contrainte de clé étrangère (ou une sorte de relation) entre les tables de profil dans MyDB et les tables de réSEAU? Une discussion de la façon dont mes tableaux personnalisés se rapportent à celles fournies par le réSEAU serait merveilleux.

Merci d'avance.

Answer 1

Il y a deux options que je peux voir, tous deux donneront essentiellement le même résultat:

• FK de dbo.aspnet_User.UserID à dbo.Profile.UserID, puis définir une clé unique sur dbo.Profile.UserID (sauf si vous utilisez comme la colonne PK pour dbo.Profile)

• FK de dbo.aspnet_Profile.ProfileID à dbo.Profile.ProfileID

dbo.aspnet_User est logiquement 1 - 1 avec dbo.aspnet_Profile, donc il n'a pas vraiment d'importance qui approche utilisez-vous que vous obtiendrez toujours la même intégrité relationnelle.

Si vous remplacez la table standard de données de profil avec votre propre mise en œuvre alors il est plus logique d'utiliser la première suggestion, sinon, si vous étendez le schéma de profil puis utilisez la deuxième suggestion.

EDIT

aspnet_Profile est la table standard - la norme SqlProfileProvider stocke les données de profil de l'utilisateur comme un sac de propriété sérialisé dans aspnet_Profile, donc pourquoi il n'y a pas de table de aspnet_ProfileData distinct.

Cette approche permet au schéma de profil pour être facilement personnalisés pour différentes applications sans nécessiter de modifications à la base de données sous-jacente, et est la solution la plus optimale pour un cadre tel que .NET. L'inconvénient est que SQL Server n'a pas accès facile à ces données du tout, il est donc beaucoup plus difficile à indexer, mettre à jour et d'interroger les données de profil de l'utilisateur à l'aide de T-SQL et la logique à base réglée.

L'approche la plus commune que je l'ai vu pour supprimer cette limitation est d'étendre la SqlProfileProvider standard pour écrire sur une table de données de profil personnalisé qui a des colonnes spécifiques pour les propriétés de profil spécifiques à l'application. Ce tableau a naturellement un 1-1 avec la table aspnet_Profile, il a donc une clé étrangère comme indiqué ci-dessus.

Le rôle du fournisseur étendu est de promouvoir les propriétés de profil spécifiques aux colonnes au cours de profil écrit et lu dans les colonnes lorsque le profil est récupéré.

Cela vous permet de sur une base selon les besoins mix-and-match solutions de stockage, tant que votre fournisseur étendu sait comment revenir à la mise en œuvre standard où il ne « sait » pas une propriété donnée.

Je pense toujours qu'il est préférable de laisser les tables d'adhésion standards-est, et d'étendre le cas échéant à l'aide de nouvelles tables avec des clés étrangères appropriées, sous-classe alors le fournisseur approprié et remplacer les méthodes de fournisseur avec votre propre implémentation (appelant dans la base la mise en œuvre chaque fois que possible).