Re: [JDBC] Thoughts on a Isolation/Security problem.
От | Achilleus Mantzios |
---|---|
Тема | Re: [JDBC] Thoughts on a Isolation/Security problem. |
Дата | |
Msg-id | Pine.LNX.4.44.0604181413330.24984-100000@matrix.gatewaynet.com обсуждение исходный текст |
Ответ на | Re: [JDBC] Thoughts on a Isolation/Security problem. (Markus Schaber <schabi@logix-tt.com>) |
Ответы |
Re: [JDBC] Thoughts on a Isolation/Security problem.
|
Список | pgsql-sql |
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
В списке pgsql-sql по дате отправления: