how do I integrate the aspnet_users table (asp.net membership) into my existing database

i have a database that already has a users table

COLUMNS:

userID - int

loginName - string

First - string

Last - string

i just installed the asp.net membership table. Right now all of my tables are joined into my users table foreign keyed into the "userId" field

How do i integrate asp.net_users table into my schema? here are the ideas i thought of:

1. Add a membership_id field to my users table and on new inserts, include that new field in my users table. This seems like the cleanest way as i dont need to break any existing relationships.

2. break all existing relationship and move all of the fields in my user table into the asp.net_users table. This seems like a pain but ultimately will lead to the most simple, normalized solution

any thoughts?

I regularly use all manner of provider stacks with great success.

I am going to proceed with the respectful observation that your experience with the SqlProvider stack is limited and that the path of least resistance seems to you to be to splice into aspnet_db.

The abstract provider stack provides cleanly separated feature sets that compliment and interact with each other in an intuitive way... if you take the time to understand how it works.

And by extension, while not perfect, the SqlProviders provide a very robust backing store for the extensive personalization and security facilities that underly the asp.net runtime.

The more effort you make to understand the workings of these facilities, focusing less on how to modify (read: break) the existing schema and more on how to envision how your existing data could fit into the existing schema the less effort you will ultimately expend in order to ultimately end up with a robust, easily understandable security and personalization system that you did not have to design, write, test and maintain.

Don't get me wrong, I am not saying not to customize the providers. That is the whole point of an abstract factory pattern. But before you take it upon yourself to splice into a database/schema/critical infrastructural system it would behoove you to better understand it.

And once you get to that point you will start to see how simple life can be if you concentrate on learning how to make systems that have thousands of man hours in dev time and countless users every minute of every day work for you the more actual work you will get done on the things that really interest you and your stakeholders.

So - let me suggest that you import your users into the aspnet_db/sqlprovider stack and leverage the facilities provided.

The userId in aspnet_db is a guid and should remain that way for very many reasons. If you need to retain the original integral user identifier - stash it in the mobile pin field for reference.

Membership is where you want to place information that is relevant to security and identification. User name, password, etc.

Profiles is where you want to place volitile meta like names and site preferences.

Anyway - what I am trying to say is that you need to have a better understanding of the database and the providers before you hack it. Start of by understanding how to use it as provided and your experience will be more fruitful.

Good luck.

In my experience, the "ASP.NET membership provider" introduces more complexity than it solves. So I'd go for option 2: a custom user table.

P.S. If anyone has been using the "ASP.NET membership provider" with success, please comment!