O Markus Schaber έγραψε στις Apr 18, 2006 : > Hi, Achilleus, > > Achilleus Mantzios wrote: > > > Now i am thinking of restructuring the whole architecture as: > > - Create one EAR app for every mgmt company > > - Create one DB USER for every mgmg company > > - Create one SCHEMA (same as the USER) for every mgmt company > > (mgmtcompany1,mgmtcompany2,etc...) > > We're doing a very similar thing here for one of our legacy apps, which > luckily does not know anything about schemas, and so the search_path > trick does work. > > However, for most "global" tables we have views with insert/update/ > delete rules in the specific schemas, and such shield the application > from directly accessing the global data. We even need to mere local and > global data this way in some cases. > > It is ugly, but it works fine and is manageable. If no exotic/contrib code is to be used then i think splitting into separate Schemas (versus separate DBs) will make future consolidation/stats/accounting (global data) code easy to write. (Unless ofcourse some real cross-db sql join features appear which is not the case at the moment). Why do you think its ugly after all? > > HTH, > Markus > -- -Achilleus
