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