Search code examples
sql-serverasp.net-mvc-4simplemembership

Should SimpleMembership database be separate in mvc4


MVC4 code first applicaiton

I will be adding two int16 fields to the UseProfile and will be starting out with about 600 users, which could potentially grow. I know how to configure SimpleMembership to be either a separate DB or rolled into the main application DB. Code wise it is a toss up which way to go. Any opinions from experienced developers as to what would be best practice in this scenario, especially in light of the scaled down schema of SimpleMembership vs. the old Membership provider. The big downside of two databases is the cost associated with hosting.

Thanks,


Solution

  • Asp.Net Membership (and SimpleMembership) work fine when in your app's database.

    The only reason why I would consider splitting the databases is if you will have multiple systems with a single user base (i.e. single sign on) - IMO this decision point was true of the old Membership as well.

    The other benefit of retaining users in the same database is for the purpose of referential integrity - e.g. a foreign key constraint from an App table to UserId will prevent accidental deletion of users, and allow easier /simpler joins between App and Membership tables.

    Howwever, you might consider keeping the membership ConnectionString separate from your app connection string, as this will keep your options open for later and your app won't be constrained to code-first EF.