Bonjour

Je découvre PostgreSQL et m'interroge sur l'utilité réelle des schémas, en dehors des accès inter-bases.

Dans la doc (5.7), on trouve ceci :
"• pour autoriser de nombreux utilisateurs à utiliser une base de données sans interférences entre eux ;
• pour organiser les objets de la base de données en groupes logiques afin de faciliter leur gestion ;
• les applications tiers peuvent être placées dans des schémas séparés pour éviter les collisions avec les noms d'autres objets."

En surfant assidument, je n'ai pas trouvé d'informations et d'exemples pratiques de l'usage de ces schémas dans la conception d'une application (oublions ici les instructions de programmation).
Certains stockent leurs procédures dans un schéma, comme le suggère le second alinéa ci-dessus, ce qui impose le nommage explicite lorsqu'on les utilise.
D'autres créent un schéma par client car ceux-ci ont des fichiers spécifiques. Je suppose qu'alors, tout ce qui touche à l'applicatif est regroupé dans un schéma qui fait fonction de serveur vis à vis des autres schémas qui sont "clients" et ne contiennent que des données.

Je ne saisis pas très bien la portée du point relatif aux interférences éventuelles entre de nombreux utilisateurs et je suppose qu'on traite là d'utilisateurs actifs effectuant de nombreuses mises à jours de fichiers de données.
Mais qu'en est-il par exemple dans le cas d'un site d'information ou de documentation où l'interactivité est limitée et se résume éventuellement à la sélection de rubriques ou à des recherches sur critères, voire à la participation à des forums comme je le fais pour l'instant sur Développez.com ?


Enfin, si je commence un développement en me contentant du schéma implicite (soit "public"), sera-t-il possible de transférer ultérieurement certaines entités (tables, procédures, ...) vers un autre schéma ?
"ALTER SCHEMA ... RENAME / OWNER ..." ne fonctionne apparemment qu'au niveau global du schéma et ne permet pas de sélection de ses composants.

Merci de m'avoir lu et dans l'attente de vos réponses.
MG