> 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