From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | "Troy Rasiah" <troyr(at)vicnet(dot)net(dot)au> |
Cc: | pgsql-general(at)postgresql(dot)org, troyrasiah(at)gmail(dot)com |
Subject: | Re: Connection to second database on server |
Date: | 2008-08-25 03:59:08 |
Message-ID: | dcc563d10808242059v1cd8b94el39e7f75888ae49c8@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Aug 24, 2008 at 8:43 PM, Troy Rasiah <troyr(at)vicnet(dot)net(dot)au> wrote:
>
> Sorry for bringing up an old post...If you have a generic set of tables..
>
> eg. table of countries / post codes etc which are used across several
> databases what is the best way to access / store them?
> I currently
> - use dblink to create views when i want to do joins,
> OR
> - i just open up a separate db handle when i just want to display the
> data (via a perl script) from the 'generic database' (eg. a select list
> of countries)
>
> but was wondering whether schema's would apply to me as well ?
Yes, schemas would be much better. The nice thing is with
search_path, you could have a setup where application1 and
application2 live in different schemas but have access to a common
schema. When running app1, you'd do something like:
set search_path='app1','commonschema';
and when running app2 you'd change the app1 up there to app2 and then
you could access the tables in both schemas without having to use
prefixes.
From | Date | Subject | |
---|---|---|---|
Next Message | Troy Rasiah | 2008-08-25 04:19:54 | Re: Connection to second database on server |
Previous Message | Troy Rasiah | 2008-08-25 02:43:36 | Re: Connection to second database on server |