Reporter le nom du schéma dans celui des tables qu'il contient

Je modélise une base complexe qui tournera sous PostgreSql alors que je suis plutôt accoutumé à MySql. Je me pose une petite question concernant le nom des tables :

• est-il intéressant de reporter le nom du schéma, ou plutôt son trigramme, dans le nom de chaque table qu'il contient ?
• Accessoirement, y a-t-il une convention qui le préconise, ou non ?

exemple :

Code:

---

1 2	CREATE SCHEMA s_boutique_sbt CREATE TABLE s_boutique_sbt.sbt_t_produit_prd

---

L'un des intérêts des schémas, c'est de pouvoir avoir des objets de même nom dans des schémas différents, tout comme on a sur un disque des fichiers de même nom dans des répertoires différents.

Or c'est contradictoire avec le fait de mettre le nom du schéma, partiellement ou pas, dans le nom de l'objet.

Ca supprime de la liberté, et côté avantage qu'est-ce que ça apporterait?

Je ne vois pas en quoi cela supprime la liberté. Par exemple, si je veux modéliser deux jeux différents mais qui comportent chacun une entité carte dont les attributs sont différents d'un jeu à l'autre :

Code:

---

1 2 3 4

CREATE SCHEMA s_jeu1_sj1; CREATE SCHEMA s_jeu2_sj2; CREATE TABLE s_jeu1_sj1.sj1_t_carte_crt. CREATE TABLE s_jeu2_sj2.sj2_t_carte_crt.

---

Peut-être suis-je un peu déformé par l'absence d'espace de nom dans MySQL que je compense en préfixant de la sorte le nom des tables ?

Si on décide qu'une table préfixée par XYZ doit être dans le schéma XYZ, ça supprime la liberté de la déplacer ou dupliquer dans un autre schéma à l'avenir, à moins de la changer de nom ce qui est très peu pratique.

Certes, si tu n'as aucune intention de faire ça dans ton projet, ce n'est pas un problème.
Il faudrait étoffer ta question avec l'objectif que tu cherches à atteindre, ou bien le problème que tu cherches à éviter, et pourquoi pas les deux.

Pour la comparaison avec MySQL, dans celui-ci l'espace de nommage équivalent au schéma de Postgres est la database, dans le sens où on fera avec MySQL une requête du style
SELECT .. FROM monautrebase.matable
à partir de n'importe quelle base pour atteindre une table dans une autre base, alors qu'avec Postgres on fera ça avec les schémas.

De ce point de vue il y a bien un espace de nommage et il peut être utilisé de manière semblable aux schémas de Postgres.

C'est vrai pour MySQL mais j'ai pris l'habitude d'utiliser les bases de MySQL dans un sens assez large pour séparer des organisations, tel que "marchand_bateau", "boutique_tissus", "boutique_jeu" le tout au sein du même SGBD et d'utiliser un préfixage pour regrouper les tables de manière fonctionnelle dans chaque base.

Ici le propos est un peu différent puisque je n'ai à faire qu'à une seule et même organisation. Je vais donc utiliser les schémas pour les regroupements fonctionnels comme je le fais avec le préfixage dans MySQL mais peut-être que dans ce cas je conçois les schémas d'une manière un peu trop restrictive.

Code:

---

1 2 3 4 5 6 7 8

CREATE DATABASE mon_organisation CREATE SCHEMA element1 CREATE SCHEMA element2 CREATE SCHEMA element3 CREATE SCHEMA adherent CREATE SCHEMA news CREATE SCHEMA administration etc.

---

Il n'y a guère de raison qu'un table puisse passer d'un schéma à un autre puisqu'aucune ne devrait avoir la même structure, cependant certaines, au sein des éléments 1 à 3 auront avoir le même nom.

En fait ma question initiale n'a pas précisément d'objectif à part à éviter d'éventuels problèmes que je n'apréhende pas encore étant donné mon inexpérience de PostgreSQL et à me conformer aux bonnes pratiques pour ce SGBD ou à une convention qui serait commune mais que je méconnaîtrais.

SQLPro ne parle pas des schémas dans ses différents écrits, desquels je me suis inspiré depuis de nombreuses années.

Citation:

---

En fait ma question initiale n'a pas précisément d'objectif à part à éviter d'éventuels problèmes que je n'apréhende pas encore étant donné mon inexpérience de PostgreSQL et à me conformer aux bonnes pratiques pour ce SGBD ou à une convention qui serait commune mais que je méconnaîtrais.

---

Pas vraiment de convention, non.

Il y a une différence à connaitre par rapport à MySQL cependant, c'est que les index sont dans un espace de nommage local au schéma, au même titre que les autres objets (tables, séquences, fonctions...) alors qu'avec MySQL il me semble que c'est local à la table.