Classer les objets Postgres en schémas logiques

Pour mieux structurer une base de données PostgreSQL, j'aime l'idée de répartir les objets en schémas logiques. Ça permet entre autre d'avoir deux tables du même nom dans deux schémas différents.

Par défaut, tous les objets sont créés dans le schéma "public". Vous ne l'aviez peut-être pas remarqué car vous n'êtes pas obligés de le nommer quand vous voulez faire référence aux objets (tables, fonctions, etc) lorsque vous construisez vos requêtes SQL.

SELECT * FROM ma_table;

Dès qu'on crée un nouveau schéma et qu'on y ajoute des objets, on devra les préfixer par le nom de schéma suivi d'un point :

CREATE SCHEMA music;

CREATE TABLE music.artist(...);
CREATE TABLE music.album(...);

CREATE VIEW music.collection(...);

SELECT * FROM music.collection;

CREATE SCHEMA movie;

CREATE TABLE movie.gender(...);
CREATE TABLE movie.title(...);

CREATE VIEW movie.collection(...);

SELECT * FROM movie.collection;

Comme vous pouvez le constater, il existe maintenant deux vues portant le nom "collection" qui reposent dans leur propre schéma. Si vous essayez de faire une requête sur la vue collection sans spécifier le schéma, PostgresSQL vous indiquera que l'objet n'existe pas (en fait, il essaiera de référencer collection dans le schéma public mais il s'arrêtera là s'il ne le trouve pas).

Cette technique vous permet d'éviter la redondance lorsque vous nommez vos tables (qui auraient aussi bien pu se nommer client_info, client_address, client_order, etc) et qui rend vos objets programmables plus modulaires puisqu'ils sont regroupés logiquement. On trouvera un avantage certain à savoir qu'un schéma possède aussi un propriétaire auquel vous pouvez donner des privilèges particuliers.