views:

230

answers:

1

I'm looking to use a slightly modified ASP.Net Membership Provider to handle the standard user account creation/authentication/etc in a website. We have a fair amount of legacy data that I need to migrate in order to provide continuity with our existing users' saved information (like order history, wishlist, etc). [NOTE: We have to migrate anyway, so this is not the reason we're migrating data]

I'm wondering what a sensible approach is for joining this additional data to the asp.net membership tables. There are a two unique keys that I could use on the user table - UserId or email - which we will use as a surrogate for username.

My question is, what is the better access pattern (and hence foreign key) to use elsewhere in my tables for storing orders, wishlists, etc?

In HttpContext, a User object is available that contains the "Username", our email address, but doesn't have the Guid for userId available.

I see 3 options:

  1. I'd like to simply use the uniqueidentifier UserId for efficiency of access over a lengthy varchar email address, but it doesn't appear readily available without extra database calls to fetch it via email/login. Is there some way to get the UserId so I can make it the foreign key on different tables?
  2. I can pass in email address (username) as the input parameter, join on userId where email address = @emailAddress, and use userId as the foreign key on other tables.

Not viable

  1. I can store username/email address on all the other tables as a foreign key - which would be an unfortunate denormalization

Any thoughts on a best method from either a DB perspective or from an application efficiency perspective?

+1  A: 

You can get UserId:

MembershipUser myObject = Membership.GetUser();
        string UserID = myObject.ProviderUserKey.ToString();

or maybe (please, check it)

  string userId = Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString();
igor
Ah, thank you - I definitely missed that. Looks like I'll use the uniqueidentifier as the join key.
jkelley
So did I two years ago. Welcome! ;)
igor
One other clarification on this - when creating a clustered index on my other tables (orders, wishlist, etc)...if my access pattern is via this GUID, won't it have poor select performance against the GUID as opposed to a natural key?
jkelley
Yes, you are right. Avoid using clustered index on GUID (any non-monotonically increasing) data type if you have many inserts to this table. If it is a static table or 1-2 inserts per day - don't worry. I think users is so table.
igor
In general the membership is the fast and temporary solution. You can quick start and in the future you need to replace it with something more flexible. Here is an example (is still in progress solution): http://www.koolzers.net/en/us/solutions/membership-service.aspx
igor