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.
Advertising
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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
