Date: Tue, 18 Apr 2006 14:26:14 +0300 (EEST)
From: Achilleus Mantzios <achill@matrix.gatewaynet.com>
To: Markus Schaber <schabi@logix-tt.com>
cc: pgsql-sql@postgresql.org, <pgsql-admin@postgresql.org>,
	<pgsql-general@postgresql.org>, <pgsql-jdbc@postgresql.org>
Subject: Re: [JDBC] Thoughts on a Isolation/Security problem.
In-Reply-To: <4444B834.1030107@logix-tt.com>
Message-ID: <Pine.LNX.4.44.0604181413330.24984-100000@matrix.gatewaynet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-7
Content-Transfer-Encoding: 8BIT

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