We have an application in which every customer has their own database, all
running from our Postgres server.
There is a large, mostly static, database of information (chemical
information), which each customer needs read access to. Lots of customer
data points to this static db, with foreign
Robert James [EMAIL PROTECTED] 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,
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,
Robert James [EMAIL PROTECTED] writes:
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...).
[ shrug... ] If your lawyers insist on that, wouldn't they also object
to all
On Nov 19, 2007 11:39 AM, Tom Lane [EMAIL PROTECTED] wrote:
[ shrug... ] If your lawyers insist on that, wouldn't they also object
to all customers linking to the same copy of the shared data? They
should, if they know what they're about.
You're implying that that lawyers understand what
On Nov 19, 2007 12:29 PM, Robert James [EMAIL PROTECTED] wrote:
Comedy aside, this makes a lot of sense:
The shared data has nothing private in it at all - it's chemical info.
Sharing it is no worse than sharing the application code, or the OS's
libraries. It's the customer's data which needs
Comedy aside, this makes a lot of sense:
The shared data has nothing private in it at all - it's chemical info.
Sharing it is no worse than sharing the application code, or the OS's
libraries. It's the customer's data which needs to be isolated.
On 11/18/07, Andrej Ricnik-Bay [EMAIL PROTECTED]
