Hello Daniel, thats exactly what we like to do with our new csp-based-Application.
Denver has mentioned some important security benefits. In addition you can also backup the data from each customer seperately and you can also move a customer-db from one to another server, etc.
I think this is a very recommend structure.
For our Application we want one central application-database/namespace APP where all app-classes/ routines/csp-sources are hold. Changes in the Application-Logic can take effect imediately in all customer areas.
There can also an ALL database/namespace if there must some data accessible from all-customers (some kind of lookups, etc.).
The mappings:
DB/Namepspace CUST1:
--------------------
Standard Global Mapping : APP
Standard Routine Mapping: APP
Global Mapping: <AppPackage>* , Data-Location : CUST1
<AppAllPackage>* , Data-Location : ALL
<AppAdminPackage>* , Data-Location : ADMINCUST2: .... CUSTX
We also need an ADMIN database/namespace which implements the Login-Server. All customer-informations needed for login (server, db/ns, user-accounts, etc.) are located there. There can also be an Admin-Console (csp-App., etc.) to add a new customer, move a customer from one to another server, etc.
Because we have a csp-Application all Logins must be routed through the login-server. (Login-csp-Page) From the given login-informations (user, password, cust.-no.) a specific url was builded for redirecting the user to the corresponed customer-csp-app./namespace. The mapping for this namespace (see above) will do the job ... i hope so ;-)
Beware in mind that this is theory for me at the moment!!!
Does Anybody has experience in this and a working/running csp-App. with that kind of structure?
I am very interessted in any comments and suggestions regarding this, especially in someone who has done something like that with success and is willing to share his experience with me/us. (db/ns/mapping-restrictions, performance-loss because of extensive mappings, configuration-issues, ...)
Thanks and Regards...
Bernd! -SHD-
[EMAIL PROTECTED] wrote:
Hello all,
We are trying to re-desing our database solution. Currently we have a setup that is similar to this:
DB1: * Setup information all Companies DB[n]: * Specific information for Company[n]
where all the DB[n]s share the same schema, but differ in the data they hold. The rationale for that was that a company specific DB could grow quite large. If all the Company Specific data was held in one big database for all client companies, a join with the company would always be required, taking a performance hit since some of those companies have quite a bit of data.
Does it make sense in Cache to split data like that? Is it just a much better solution to have the data all in one DB, instead of spread out?
I know I might not be explaining myself very clearly, I could try to explain it in a different way if it would make it easier to understand.
Thanks for your thoughts,
Daniel.
