views:

344

answers:

2

Hi,

I'm in early development stage of developing a web application. Im currently reviewing as to whether I should use ASP .NET Membership or write my own. Im more lenient towards to using ASP .NET Membership to save me some development time. Need help to clear up some ambiguities on how to best utilize membership database:

  • Membership creates a new database. Which one is better, to use the same database for my application database OR creating a new database for my application? Why?
  • If I go for creating a new database for my application. Which one is better, creating a new user table in my application database or reusing/extending the user table in the membership database?

Thanks in advance,

RWendi

+2  A: 

I myself am a fan of the Membership/Roles/Profile providers so I'm a bit biased. Basically if I were to evaluate what to use for a project I would look at the requirements. I can see no reason to implement your own membership functionality if the default works for you. It has many features and some pretty good optimizations (like columns with lowercase username and email for performance reasons).

I usually create a single database for my data and my membership. I link other tables by adding a username column but not a foreign key to avoid problems with deleting users. What is more the GUID that is the user id cannot be retrieved with the membership provider interface and you will need to write your own stored procedure if you want to reference stuff by user id.

Stilgar
+1 - DRY - Don't Repeat Yourself - if a good membership/role system exists and handles all you need (or even if you can easily extend it to handle all your needs) - use it! Don't reinvent the wheel for the gazillionth time :-)
marc_s
A: 

On the question of separate database or not, separate tends to be the way to go if you have the resources (eg--you aren't on a shared host with a single sql server db). The main advantage is that the user data tends to be pretty application specific (eg--you don't need production user data in QA), so having it live separately makes things a bit cleaner as you only need to schlep about the application's data.

Wyatt Barnett