views:

107

answers:

2

I have an existing database with users and administrators in different tables. I am rewriting an existing website in ASP.net and need to decide - should I merge the two tables into one users table and just have one provider, OR leave the tables separated and have two different providers.

Administrators, they need the ability to create, edit and delete users. I am thinking that the membership/profile provider way of editing users (i.e.

System.Web.Profile.ProfileBase pro = System.Web.Profile.ProfileBase.Create("User1");
pro.Initialize("User1", true);
txtEmail.Text = pro["SecondaryEmail"].ToString();

is the best way to edit users because the provider handles it? You cannot use this if you have two separate providers? (because they are both looking at different tables).

Or should I make a whole lot of methods to edit the users for the administrators?

UPDATE: Making a custom membership provider look at both tables is fine, but then what about the profile provider? The profile provider GetPropertyValues and SetPropertyValues would be going on the same set of properties for users and admins.

Mike

+1  A: 

Probably you should merge the two tables into one and use a RoleProvider to make the distinction between administrators and "normal" users.

Alternatively, you could implement your own, custom membership provider, which would use both tables.

M4N
im using a custom membership provider at the moment. Looking at it from one perspective, administrators are not users, they have just about no similarities to users (no properties), but they want to log in like a user, and edit users.
Mike
@Mike - 'administrators are not users', 'they just want to log in like a user and edit users' - ?!?! - I have to tell you this is a highly unusual perspective and one that might indicate that there are future design crisis coming... ;-)
Sky Sanders
A: 

Mike, My advice is to go ahead and merge your two 'membership' tables and segregate admins from non with roles.

(This is, I know a duplicate of the previous answer but I feel the need to explain..)

In this way, unless you have some compelling reason to implement custom providers, you will be able to leverage the stock providers and database structure to provide a robust user management story for your website without writing any code (that you have to test and maintain).

.2 pesos....

Sky Sanders
The main reason I'm using custom providers is that I already have an existing database, and existing schema which I have to use. I can't use the default stock providers because of this reason.
Mike
@Mike, then you have your work cut out for you. ;0) good luck.
Sky Sanders