views:

301

answers:

3

I'm using the SQLMembershipProvider and want to add a load more info about the users. It the best way to do this to create a new DB and make an entry for each new user as they are created? If so, is there any reason not to use the SQLMembershipProvider UserID value as the PK in the users table in my new DB?

Or, are there any good reasons to create a new UserID in my new DB and use the SQLMembershipProvider UserID as the FK?

+1  A: 

I cannot think of a reason why that wouldn't work or why you shouldn't do it that way (userid as PK)

I'm not sure why you'd use a separate database for everything, I'd probably just create the table in the current database and set it up using the userid as a FK to the aspnet_users table.

John Boker
True. No reason to use a seperate DB. I was just using the NerdDinner project as a template and they've used a seperate DB in that.
Mr. Flibble
+1  A: 

If you are going to be rewriting the membership provider I would switch all of the PK columns to BITINT from GUID. I would do this for two reasons; one sequential numbers are much easier to work with and understand and second there are performance benefits of using BIGINT instead of GUID Ids. I would also just use my own id column that can be used to like other tables in the application and remove the one that come by default in the sql membership provider. To do this you will need to provide code for each function in the provider, it no small task.

Lukasz
A: 

I've created a wrapper around my existing database schema, with a class derived from MembershipUser that contains the additional properties, and a MembershipProvider derivative that creates instances of the derived MembershipUser class.

I only use the Membership authentication and update methods, since the other supporting APIs are somewhat limited. I have a separate create/edit user API for admin use.

This solution is currently being used on several sites, and works well.

devstuff