Skip site navigation (1) Skip section navigation (2)

Re: CREATE SYNONYM ...

From: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>,"Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>,Michael Glaesemann <grzm(at)myrealbox(dot)com>,pgsql-patches(at)postgresql(dot)org, eg(at)cybertec(dot)at
Subject: Re: CREATE SYNONYM ...
Date: 2006-03-08 07:35:10
Message-ID: 440E892E.6060606@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-patches
> I agree with this to some extent.
> 
> The main use case, aside from database link objects, is really for 
> generally large applications such as a large ERP system.  Most ERP 
> systems have a general or foundation-like schema where common objects 
> lie and each module is separated using schemas.

absolutely - just like jonah stated before; it is not about 100 lines 
PHP code.
recently PostgreSQL was more and more adopted for "enterprise 
applications" (whatever this might be).


> As an example, you would have HR, AP, AR, GL, FA, COMMON, ... schemas 
> which encapsulate the functionality of their respective modules whether 
> it be procedures, functions, views, tables, etc.  For each module to be 
> able to access, for example, the HR.EMPLOYEE table, they generally refer 
> to just EMPLOYEE which is a synonym to HR.EMPLOYEE.
> 
> Now, one may argue that it's incorrect/bad application-design to not use 
> fully qualified names, however, there are cases (especially in VERY 
> large database applications) where you do not want to use fully 
> qualified naming.  In PostgreSQL, the alternative to synonyms is to have 
> a monstrous search path $user, public, HR, AP, AR, GL, FA, COMMON...  
> Not that we have Oracle Applications running on PostgreSQL, but 11i has 
> something like 130+? schemas which would be pretty nasty and 
> semi-unprofessional as a search_path rather than as something defined 
> similar to synonyms.  Another consideration is poor application design 
> which uses the same named table in one schema which acts differently 
> than the same named table in another schema... synonyms resolve this 
> issue which could be problematic if not impossible to solve using 
> search_path alone.

nothing to add - this is how things work in reality ...

	hans


-- 
Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at

In response to

pgsql-patches by date

Next:From: Hans-Jürgen SchönigDate: 2006-03-08 07:43:49
Subject: Re: CREATE SYNONYM ...
Previous:From: Hans-Jürgen SchönigDate: 2006-03-08 07:29:06
Subject: Re: CREATE SYNONYM ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group