Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.
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.