Craig, Without knowing what exactly he is hosting I would now dare to give your answer :-)
As a hosting company offering database hosting to customers, putting customers in one database or asking them just "who they are" would be terrific in a court case :-) On the other hand, he might be providing a service for which customer data is stored in a database - i.e. he controls the application and the customer does not access the SQL Server directly, like for a bank. In this case (like a document management system, for example) handling all customers in one database is valid :-) It is even valid to have customers "tell you who they are" - in the hope that this DOES imply that there is a password. You are right, though - strange things happen - I remember a story of a guy who had google delete his whole website from a content management system just by following links. The critical question here is - what does "hosting" mean in this context? Is there a specific application? In general, when going against different databases, but especially as going there with different users, will severely harm the usefulness of connection pooling. Switching a database on an existing connection is extremely fast, but you are right - different usernames/passwords definitely go into different pools. That said, anyone of you ever tried using COM+ pooled components to keep the database connections? According to one book there are some very good advantages in this, like controlling the minimum amount of connections and the lifetime before the application shuts down. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Craig Andera [mailto:[EMAIL PROTECTED]] Sent: Donnerstag, 23. Mai 2002 05:58 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier > The design we are taking is that when we start hosting, we > have to keep different clients data in different databases, > at least that's what my boss says because the clients > wouldn't go for their data sharing a DB with another company. > Of course, we can't put to many companies data on one SQL > server, so we were going to have everybody pass in what > company they belonged to and we would know what server and DB > to use for that user. I really hope I'm reading this wrong. You're going to let the *clients* tell you who they are? This is analogous to being able to withdraw money from my bank account because I say I'm Craig Andera. I have to assume that there's a password in here somewhere, but you wouldn't be the first person to try to do it the wrong way, so I thought I'd ask. In any case, you can only pool connections that have exactly the same server, username, password, etc., so if you split across multiple databases, your pooling will necessarily be less effective. Honestly, I think clients concerns about you being in the same DB as other companies' is weak at best. Presumably, if I compromise your app, they're just as screwed whether the data is in one DB or many. Unless they think that it's somehow going to magically leak across rows... You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
