Discussion :

[Hemgé]

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

[gleu_]

Si je reformule un peu la doc, je dirais que ça facilite principalement la gestion des droits et le travail de l'administrateur.

Disons que je veux installer un module contrib comme, disons, TSearch2. Ce dernier va installer des nouveaux types, des nouvelles fonctions, voire même une méthode d'indexage. Si je planque tout ça dans un schéma, sa suppression sera ensuite aisée.

[GrandFather]

Bonjour,

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 ?

Les informations qui vont être stockées dans cette base peuvent être classées grosso modo en deux catégories : celles qui concernent les comptes d'utilisateur (pseudo, mot de passe, email, etc.), et celles liées au contenu rédactionnel.

Dans un contexte d'entreprise, il est fort probable que ces deux catégories vont être gérées par des entités différentes ; les RH se chargeront des données concernant les utilisateurs habilités, tandis que les rédacteurs qui alimenteront l'autre catégorie pourront être issus de différents services de l'entreprise. Chaque intervenant d'un domaine n'est pas censé intervenir sur l'autre, d'où l'utilité de placer les informations de chacun de ces domaines dans son schéma spécifique pour les cloisonner. Dans le schéma "public" on placera les relations nécessaires au site pour fonctionner, mais il n'y aura pratiquement pas de tables, que des vues ou des procédures stockées qui font appel aux tables des deux autres schémas.

Avec cette structure, la définition des rôles d'utilisateurs et la définition des droits d'accès à chaque table devient bien plus simple que si tout avait été placé dans un seul schéma (le schéma "public"), tout en assurant la sécurité, la confidentialité et le cloisonnement fonctionnel.

[Hemgé]

Merci pour vos réponses.
Cela devient plus clair.

Reste le problème du reclassement ultérieur d'un fichier, d'une vue ou d'une prodédure d'un schéma dans un autre.
Apparemment, pas de solution autre que le copier/couper - coller ?

[gleu_]

Je ne sais pas ce que tu entends par déplacement de fichiers.

Par contre, si tu parles du déplacement d'un objet de la base (étant donné que tu parlais de vue et de procédure stockée) vers un autre schéma, la plupart (tous ?) des objets possèdent une instruction du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER <type_objet> <nom_objet> SET SCHEMA <nouveau_schema>

. Par exemple, pour une procédure stockée, tu feras :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER FUNCTION ma_fonction SET SCHEMA mon_nouveau_schema;

Et pour une vue, tu feras :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER TABLE ma_vue SET SCHEMA mon_nouveau_schema;

(parce qu'une vue est considérée comme une table un peu spéciale).

Voir http://www.postgresql.org/docs/8.2/i...ltertable.html, http://www.postgresql.org/docs/8.2/s...rfunction.html, et certainement d'autres.

[Hemgé]

Oui, objet plutôt que fichier !! Oups.


Avec cela, je sais TOUT
Pas mal pour un débutant, non ?

Merci à tous