Relation entre les tables du fournisseur d'appartenances ASPNET et les tables d'appartenance personnalisées

Question

J'ai parcouru un exemple de fournisseur de profil personnalisé il y a quelques temps et je suis maintenant en train de le revisiter.

Ma base de données contient toutes les tables dbo.aspnet_ * créées lors de l'exécution de l'assistant d'enregistrement aspnet . Dans ces tableaux, j'ai aspnet_Profile qui a une contrainte FK pointant sur aspnet_Users.

J'ai également 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 est comment les tables dans MyDB se rapportent à ceux dans dbo.aspnet_ *. Ne devrait-il pas y avoir une contrainte de clé étrangère (ou une sorte de relation ) entre les tables de profil dans MyDB et les tables aspnet? Une discussion de comment mes tables personnalisées se rapportent à celles fournies par aspnet serait merveilleuse.

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 le PK la colonne pour dbo.Profile)

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

dbo.aspnet_User est logiquement 1 - 1 avec dbo.aspnet_Profile, donc peu importe l'approche que vous utilisez car vous obtiendrez toujours la même intégrité relationnelle. Si vous remplacez la table de données de profil standard par votre propre implémentation, il est plus logique d'utiliser la première suggestion, sinon, si vous étendez le schéma Profile, utilisez la deuxième suggestion.

EDIT

aspnet_Profile est la table standard - les SqlProfileProvider standards 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 aspnet_ProfileData distinct.

Cette approche permet de personnaliser facilement le schéma de profil pour différentes applications sans nécessiter de modification de la base de données sous-jacente. C'est la solution la plus optimale pour un framework tel que .NET. L'inconvénient est que SQL Server n'a aucun accès facile à ces données, il est donc beaucoup plus difficile d'indexer, mettre à jour et interroger les données de profil de l'utilisateur en utilisant T-SQL et la logique basée sur les ensembles.

L'approche la plus courante que j'ai vu pour supprimer cette limitation est d'étendre la norme SqlProfileProvider pour écrire dans 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. Cette table a naturellement une relation 1-1 avec la table aspnet_Profile, donc elle a une clé étrangère comme indiqué ci-dessus.

Le rôle du fournisseur étendu consiste à promouvoir des propriétés de profil spécifiques pour les colonnes pendant les écritures de profil et à les lire dans les colonnes lorsque le profil est extrait.Cela vous permet de mélanger les solutions de stockage en fonction des besoins, à condition que votre fournisseur étendu sache comment revenir à l'implémentation standard où il ne «connaît» pas une propriété donnée. Je pense toujours qu'il est préférable de laisser les tables d'appartenance standard telles quelles et de les étendre si nécessaire en utilisant de nouvelles tables avec des clés étrangères appropriées, puis de sous-classer le fournisseur approprié et de surcharger les méthodes du fournisseur avec votre propre implémentation. mise en œuvre de base dans la mesure du possible).