ASP.NET Membership Database vs. Membership AND User Database

Question

Is there any reason why I shouldn't add contact and extended data to the users database with a custom membership provider?

What is the advantage of keeping separate one-to-one tables for user data and membership data? As I understand it, the common method is to keep separate tables. I'm thinking it would be better to have one table for users to keep SQL statements simple and custom code the membership provider.

Answer 1

The idea behind Membership is that it provides a plug-and-play generic membership solution. Say you want to switch from Sql to ActiveDirctory, you need only change the membership provider and everything works.

So long as you are creating a custom provider, you can do whatever you want. But, in order to get your extra data into the membership tables, you will have do so outside of the membership interface (because the API does not include fields for them). That means, you are essentially throwing away the Membership API.

My advice is to either a) use Membership as it was intended, or b) go off and do your own thing completely. Don't try to shoehorn Membership into something it's not intended for.

But, writing your own is a lot more involved than you might at first think, at least if you want to e be secure and cover all your bases.

Answer 2

The advantage is separation of concerns. By keeping them in separate tables, you're in a situation where the membership data store could be swapped out or modified in isolation. However, before getting too excited about the "flexibility" consider the realistic lifespan of your application. Weigh the likelihood of needing to change things in the future vs the upfront cost of implementing a custom provider.

When I've implemented custom membership providers, more often then not I've found myself at one point actually wishing I had just rolled a completely custom authentication mechanism. Once you've implemented the provider interface, you don't necessarily gain a whole lot by "plugging into" the rest of the provider infrastructure. For simple apps, I'd usually just recommend doing the simplest, easiest thing that works. If you haven't build many authentication systems, you might find the process of implementing a custom provider educational.