views:

52

answers:

1

Is it better for a collection of ASP.NET web apps to share the same session database, or should each one have its own?

If there is no significant difference, having a single database would be preferable due to easier maintenance.

Background

My team has an assortment of ASP.NET web apps, all written in either Monorail 1.1 or ASP.NET MVC 1.0. Each app currently uses a dedicated session state database. I'm working on adding a new site to that list, and am debating whether I should create another new session database, or just share an existing one with another app.

+2  A: 

I would vote for separation here.

I don't think you'll necessarily find that it's "easier maintenance" in the long run to stuff everything into one database. If every app is using the same table and database instance, you can't separate one application from the pool without duplicating the entire database. What if one app goes viral and needs to be moved to it's own server cluster?

For the amount of work it takes to copy a database to a new instance, you'll be separating the concerns of the applications, making it easier to debug them individually, more scalable and much more portable.

womp
But would it hurt to push off the creation of additional databases until they are needed? If one of the apps needs more horsepower, I'm simply back where I started, and would need to create a separate DB for that app. The other apps could still share the same DB.Or, are you basically suggesting that it would be silly to do the work to move these apps over to a single state database, since they are already configured with individual ones?
MikeWyatt
Try to imagine you need to split everything down the middle, and move half the apps. Now you need to go change the config file for several apps and test them all again. Or imagine you need to add a special index to the table for one app - now all your other apps suffer for write performance. I just don't see any advantage to creating a huge spaghetti heap for a database just because you want to save yourself some work upfront.
womp
I don't really agree with the shared database being a "huge spaghetti heap". Each app's Web.config simply points to a common database, and that is trivial to change in the future.I see your point about changes to the database affecting multiple apps, though. I don't want to tell my manager that we need to redeploy multiple applications because of a change made for a single app. That reason alone is probably enough to have separate databases.
MikeWyatt