> I don't think it's a weak argument at all. By combining data, > you run the risk that a bug in your code could reveal their > data to a competitor. At least with database isolation, that > becomes far less likely.
Hmm. I guess this is one of those situations where it comes down to what you think the risk is. I could argue that if you have a DB per customer, and presumably the tables have the same structure in each DB, all you've done is move the coding error from the WHERE clause that filters by customer to the code that selects the connection string. I'm willing to respect your opinion that the latter is an easier mistake to make, but I don't think we can objectively measure the relative liklihood. > Besides, from a scalability standpoint, even if you have > moderate amounts of data per client, when you have many > clients, the database becomes slow. Backup and taking clients > out is much easier with single databases. It's true that partitioning is the key to scalability, and customer boundaries make a great way to decide what your partitions should look like. I'd buy this argument over liklihood of coding errors any day. Against this weigh increased cost of maintenance (admin costs go up with the number of boxes, although not linearly). Perhaps that's not a factor in this case. > I've been in both boats, and I'd take separate databases every time. I don't think it's a slam dunk, but I can certainly see the argument for some scenarios. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
