tradeoffs for multi-schema or multi-db

From: "Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)com>
To: <pgsql-general(at)postgresql(dot)org>
Subject: tradeoffs for multi-schema or multi-db
Date: 2007-09-18 16:36:26
Message-ID: D7FF158337303A419CF4A183F48302D603179FE2@hdsmsx411.amr.corp.intel.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Here's the situation...

I have 2 different apps that both require a separate shema, or maybe db.
There is actually one column in one table of each ot these db/schemas
that are in common and a desire to :cross" between them in some cases.
For example, an app for keeping track of the census results and another
app that keeps track of criminal cases in the justice system. They
"shared" field is of course the citizen/defendant. Two different apps
that should remain separate, but at times it would be nice to check the
legal status of the defendant by looking at the census data.

Considering the somewhat rare query that will need to bridge these 2
data sources (dbs or schemas), what are the pros/cons of having 2
schemas in the same DB vs 2 DBs? What if the query is to be committed
to a PLpgsql function/procedure? How awkward is it to bridge schemas vs
bridging dbs in that form?

Thanks for any advise/help.

-dave

Browse pgsql-general by date

  From Date Subject
Next Message Steve Atkins 2007-09-18 16:43:39 Re: ON INSERT => execute AWK/SH/EXE?
Previous Message Steve Crawford 2007-09-18 16:35:30 Optimizing "exists"