2

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?

Simon
  • 25,468
  • 44
  • 152
  • 266
Mr. Flibble
  • 26,564
  • 23
  • 69
  • 100
  • This depends on the nature of the information you're trying to add of course, but have you considered using the profile functionality to store the information instead? – Brant Bobby Jul 29 '09 at 16:04
  • Thanks Brant. I hand't come across the profile functionality before. Just read http://aspnet.4guysfromrolla.com/articles/101106-1.aspx which is a good intro to it. It won't be suitable for this project tho, unless I made my own profile provider. – Mr. Flibble Jul 30 '09 at 01:18

3 Answers3

2

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
  • 82,559
  • 17
  • 97
  • 130
  • 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 Jul 30 '09 at 01:19
1

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
  • 8,710
  • 12
  • 44
  • 72
0

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
  • 8,277
  • 1
  • 27
  • 33