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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to