2

J'utilise le SQLMembershipProvider et je veux ajouter un chargement plus d'informations sur les utilisateurs. Est-ce la meilleure façon de le faire pour créer une nouvelle base de données et 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 pour ne pas utiliser la valeur SQLID de UserMinderProvider comme PK dans la table des utilisateurs dans ma nouvelle base de données?Extension du fournisseur d'appartenance ASP.NET, PK == FK == OK?

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?

+0

Cela dépend de la nature des informations que vous essayez d'ajouter, mais avez-vous envisagé d'utiliser la fonctionnalité de profil pour stocker les informations à la place? –

+0

Merci Brant. Je n'ai jamais rencontré la fonctionnalité de profil avant. Il suffit de lire http://aspnet.4guysfromrolla.com/articles/101106-1.aspx qui est une bonne intro. Il ne sera pas adapté à ce projet, sauf si j'ai créé mon propre fournisseur de profils. –

Répondre

2

Je ne peux pas penser à une raison pour laquelle cela ne fonctionne pas ou pourquoi vous ne devriez pas le faire de cette façon (userid PK)

Je ne sais pas pourquoi vous utilisez une base de données séparée pour tout , Je créerais probablement la table dans la base de données courante et l'installerais en utilisant le userid comme un FK à la table d'aspnet_users.

+0

True. Aucune raison d'utiliser une base de données séparée. J'utilisais simplement le projet NerdDinner comme modèle et ils ont utilisé une base de données séparée. –

1

Si vous allez réécrire le fournisseur d'appartenances, je passerais toutes les colonnes PK à BITINT à partir de GUID. Je le ferais pour deux raisons; un nombre séquentiel est beaucoup plus facile à travailler et à comprendre et, en second lieu, il y a des avantages de performance à utiliser BIGINT au lieu d'ID GUID. Je voudrais également utiliser ma propre colonne id qui peut être utilisée pour aimer les autres tables de l'application et supprimer celle qui vient par défaut dans le fournisseur d'appartenances sql. Pour ce faire, vous devrez fournir du code pour chaque fonction dans le fournisseur, ce n'est pas une mince tâche.

0

J'ai créé un wrapper autour de mon schéma de base de données existante, avec une classe dérivée de MembershipUser qui contient les propriétés supplémentaires, et un dérivé MembershipProvider qui crée des instances de la classe MembershipUser dérivée. Je n'utilise que les méthodes d'authentification et de mise à jour de l'appartenance, car les autres API de support sont quelque peu limitées. J'ai une API utilisateur create/edit distincte pour l'administration.

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

Questions connexes