I am using the ASP.Net 2.0 Membership tables and would like to add my own User_Profile table and connect it back to the aspnet_Users table.
Usually I always have the Primary Key be the same as the table name for example my User_Profiles table would have a UserProfileID, my Languages table would have a languageID.
In this case I found this sample
The first - which affords the greatest flexibility, but requires the most upfront effort - is to create a custom data store for this information. If you are using the SqlMembershipProvider, this would mean creating an additional database table that had as a primary key the UserId value from the aspnet_Users table and columns for each of the additional user properties. In the online messageboard example, the table might be called forums_UserProfile and have columns like UserId (a primary key and a foreign key back to aspnet_Users.UserId), HomepageUrl, Signature, and IMAddress.
where it suggests I just use the UserID as the Primary Key in my User_Profiles table. Looking at my database design I could use the UserID in many places as my Primary Key instead of having a Primary Key which relates to the table name and then UserID as just a column in the table.
Are there any pros and cons? Which one is better database design? What is best practice?
Thanks,
Newbie
Hi,
UserID is the promary key in Users table (like aspnet_Users) and a FK in related tables (like UserProfile etc). Since each profile can be identified by the userID only, there is nothing wrong in having it as the PK of the same table. Why would you like to have a surrogate key for such a table (when it doesnt really need one). IMHO, this is fine.
Vivek
No comments:
Post a Comment