Hi,

Can anyone point me to a article or product about using an application hosted on a webserver for multiple customers? So everything is the same except for the connection string each customer runs with, which gets loaded upon logon. (Use llbl gen for that)

My situation is a following: - 1 set of code which can interact with the database - 1 SQL Server instance with multiple Databases (1 per customer) - 1 File Storage Folder with a folder in which a structue for each client resides

Is this a keepable structure in performance? Are there better "best practices"?

Any comments will be appericiated!

Greets, Gab

I cannot point you to any archicles or product, but one way of doing this would be:

Have a single 'Login' database that serves all your customers - you need authentication/authorisation anyway. This login DB will contain the username/password, customer Id, connection string.

When smeone logs in, you use the 'default' connection string to validate the user, then use his connection string to logon to HIS specific DB by modifying the connection string.

I've been working on a mult-tenancy app as well. Right now, I have the app database that stores the user and role tables in the database itself. I've been wondering if it would be better to store the users and roles info in a seperate login database or add these to the actual application db itself. Comments would be helpful (ie advantages vs. disadvantages).

Jusy my view:

The biggest advantage of a seperate login DB, I guess, is that all your users and roles are centralised in one place. This also gives you the potential to use or migrate to other A/A technologies such as Active Directory.

From a security point of view, this enables you to 'lock down' all your client DB's by potentially implementing a single user ID/password to access client DB. Connection pooling works great when the connection string is 'static', a performance bonus.

Client DB's will only consist of 'application data' and could therefore simplify recovery when there is disaster.

I am sure there are also a few disadvantages as well...

Thanks for the help...

What I've done is a login db per client. When a user log's on he has a third credential, company code, which will tell the software where to look.

Also this way makes it possible to have username double (so each client can have the user John, Caroline, etc.).

Greets, Gab