Another advantage to separate databases is, what if one client calls in and says, "hey, we FUBARed our data and need you to restore from last night's backup"? If you have one database for all clients, forget it, ain't gonna happen. If you have one database per client, this is easy. Get smart about the maintenance, and you can even ask, "Is last night's backup good enough, or would you rather have it restored to one hour ago, or noon or whatever?", assuming you run diff/log backups periodically throughout the day.
The main one, however, is the ability to add servers without having to federate the database. Maybe you don't have any one client that's big enough to need their own server, but what happens if you can really only get decent performance for 10 clients on one server, and you get 12 clients? Multiple databases, it's easy, put 6 on each server. One database with 12 clients? Not so easy.
I also have to ask about having to propagate all structure changes to all databases (on all servers). Is that really necessary in this case? If one customer wants a table called "Widgets", do all of your clients really need that table?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon