From: | "Robert James" <srobertjames(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | "Douglas McNaught" <doug(at)mcnaught(dot)org> |
Subject: | Re: Sharing static data among several databases |
Date: | 2007-11-18 22:31:18 |
Message-ID: | e09785e00711181431r40f13787m716414649363a869@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks. For legal requirements, we need to keep each customer in a fully
isolated, separate db. (I'm not very familiar with schema - perhaps they
can do the same thing...).
What about just dropping the FKs? Can we do cross DB joins? Are there
significant performance penalties?
On 11/18/07, Douglas McNaught <doug(at)mcnaught(dot)org> wrote:
>
> "Robert James" <srobertjames(at)gmail(dot)com> writes:
>
> > 1.) Is there a way of separating, isolating, and sharing the shared data
> that
> > will still allow FKs to it?
>
> The only approach I know of would be to make all your customers use
> independent schemas in one database, with isolation via appropriate
> permissions, and have your shared data in another schema that all the
> users have read access to. Each user could have a search_path that
> contained their schema and the shared schema, which should minimize
> the amount of query-changing you'd need to do.
>
> Note that this is basically what you would do with Oracle--it doesn't
> have a concept of "database" really, just an "instance" that contains
> schemas (which map more-or-less onto database users).
>
> It would certainly be a change in your architecture, but how much work
> it would be I don't know...
>
> -Doug
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-11-18 22:39:54 | Re: Sharing static data among several databases |
Previous Message | Matt Magoffin | 2007-11-18 22:24:47 | Re: 8.3b2 XPath-based function index server crash |