3

which is better and why?

Improve this question

2 Answers 2

Reset to default
6

It's perfectly acceptable to keep them in the same database. It's easy to work with and do joins as needed, and the database backs up and moves together. If you plan to share the membership with other applications, then you should consider separating them and making them more modular.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

you can just as easily join across databases on the same server, albeit with more qualified names.
Yeah, and even joining to other servers isn't difficult with linked servers. Yet, it's acceptable and easy to just have them in the same database for many projects. The question doesn't give enough details to answer with specifics, so it's hard to give a specific answer.
3

If your site database contains it's own structure for membership, then I'd be inclined to write a custom Membership Provider to pull the data from that.

If you're using the default ASP.NET Membership database, you might want to keep it separate as it can be used by more than one application.

Whilst there's nothing stopping you from combining it with your site database and also using it with another application, it might start to get a little confusing, particularly if that other application has it's own database for application-centric data, but then is getting membership data from a now combined database of the original site plus the ASP.NET Membership database.

In summary, I'd keep it separate. No real good reason springs to mind as to why one would need to combine them, or it being better to do so.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.