Extension du fournisseur d’adhésion ASP.NET, PK == FK == OK?

Question

J'utilise SQLMembershipProvider et souhaite ajouter plus d'informations sur les utilisateurs. Est-ce la meilleure façon de créer une nouvelle base de données et de créer une entrée pour chaque nouvel utilisateur au fur et à mesure de leur création? Si tel est le cas, y a-t-il une raison quelconque de ne pas utiliser la valeur ID utilisateur SQLMembershipProvider en tant que clé publique dans la table users de ma nouvelle base de données?

Ou existe-t-il de bonnes raisons de créer un nouvel ID utilisateur dans ma nouvelle base de données et d'utiliser l'ID utilisateur SQLMembershipProvider comme FK?

Answer 1

Je ne vois pas pourquoi cela ne fonctionnerait pas ou pourquoi vous ne devriez pas le faire de cette façon (ID utilisateur en tant que PK)

Je ne suis pas sûr de savoir pourquoi vous utiliseriez une base de données séparée pour tout, je créerais probablement la table dans la base de données actuelle et la configurerais en utilisant l'ID utilisateur en tant que FK pour la table aspnet_users.

Answer 2

Si vous êtes sur le point de réécrire le fournisseur d’adhésion, toutes les colonnes de la clé PK doivent être remplacées par un GUID pour BITINT. Je le ferais pour deux raisons. un numéro séquentiel est beaucoup plus facile à utiliser et à comprendre, et deuxièmement, l’utilisation de BIGINT au lieu des ID GUID présente des avantages en termes de performances. Je voudrais également simplement utiliser ma propre colonne d'identifiant qui peut être utilisée pour aimer les autres tables de l'application et supprimer celle qui est fournie par défaut dans le fournisseur d'appartenance SQL. Pour ce faire, vous devrez fournir du code pour chaque fonction du fournisseur, ce n’est pas une mince tâche.

Answer 3

J'ai créé un wrapper autour de mon schéma de base de données existant, avec une classe dérivée de MembershipUser contenant les propriétés supplémentaires, ainsi qu'un dérivé MembershipProvider créant des instances du classe MembershipUser dérivée.

J'utilise uniquement les méthodes d'authentification d'adhésion et de mise à jour, car les autres API de support sont quelque peu limitées. J'ai une API utilisateur distincte pour la création / édition à utiliser par l'administrateur.

Cette solution est actuellement utilisée sur plusieurs sites et fonctionne bien.