Que sont les schémas dans PostgreSQL ?

Question

Accepted Answer

Un **schéma** dans PostgreSQL est un **namespace** au sein d'une base de données — un conteneur logique qui regroupe les tables, vues, fonctions et autres objets associés. Les schémas vous permettent d'organiser les objets et d'éviter les collisions de noms ; le schéma par défaut est `public`.

## Les schémas organisent les objets au sein d'une base de données

```text
A PostgreSQL server can have multiple DATABASES.
Each database can have multiple SCHEMAS (namespaces).
Each schema contains TABLES, views, functions, etc.
→ Hierarchy: server → database → schema → tables/objects
```

```sql
CREATE SCHEMA sales;                    -- create a schema
CREATE TABLE sales.orders (...);         -- a table IN the sales schema (qualified name)
SELECT * FROM sales.orders;              -- reference with schema.table

-- the default schema is `public` — unqualified objects go there
CREATE TABLE users (...);                -- actually public.users
```

Les objets sont référencés sous la forme `schema.object`. Sans préfixe de schéma, Postgres utilise le **chemin de recherche** (par défaut : `public`).

## Le chemin de recherche

```sql
SHOW search_path;                        -- default: "$user", public
SET search_path TO sales, public;        -- look in sales first, then public
SELECT * FROM orders;                    -- finds sales.orders (no prefix needed)
```

Le **chemin de recherche** détermine les schémas dans lesquels Postgres recherche les noms non qualifiés — le configurer vous permet d'utiliser des noms courts au sein d'un schéma choisi.

## Pourquoi utiliser les schémas

```text
✓ ORGANIZATION — group related objects (e.g. `sales`, `inventory`, `auth` schemas)
✓ Avoid naming collisions — two schemas can each have an `orders` table
✓ MULTI-TENANCY — a schema per tenant (isolating each customer's data)
✓ SECURITY/permissions — grant access per schema
✓ Separating concerns — e.g. an `app` schema vs an `analytics` schema
```

Un pattern courant est un **schéma par locataire** dans les applications multi-locataires, ou un regroupement par domaine/module.

## Pourquoi c'est important

Les schémas sont une fonctionnalité PostgreSQL utile pour **organiser les objets de la base de données**, et les comprendre est précieux pour structurer les bases de données correctement, en particulier lorsqu'elles se développent ou servent plusieurs locataires.

Comprendre qu'un schéma est un namespace au sein d'une base de données (regroupant tables, vues, fonctions) — avec la hiérarchie serveur → base de données → schéma → objets — clarifie la façon dont Postgres organise les objets et comment les référencer (`schema.object`, ou en s'appuyant sur le **chemin de recherche** pour les noms non qualifiés, par défaut `public`).

Connaître les **usages pratiques** est la clé de la valeur : les schémas offrent une organisation (regroupement des objets associés par domaine/module — `auth`, `sales`, `analytics`), évitent les collisions de noms (différents schémas peuvent avoir des tables portant le même nom), permettent la sécurité/les permissions par schéma, et soutiennent de façon cruciale la **multi-location** (un pattern courant d'un schéma par locataire pour isoler les données de chaque client — une option architecturale importante pour les applications SaaS).

Comprendre les schémas et le chemin de recherche vous aide à organiser une base de données de façon propre, à éviter le désordre et les collisions de tout mettre dans `public`, et à implémenter des patterns comme la multi-location.

Puisque l'organisation logique des objets de la base de données importe pour la maintenabilité (particulièrement dans les applications plus grandes), et puisque les schémas activent des patterns importants (séparation de domaine, multi-location, sécurité par schéma), comprendre les schémas PostgreSQL — ce qu'ils sont, le chemin de recherche, et leurs usages pratiques — est une connaissance précieuse et pratiquement pertinente pour structurer les bases de données Postgres efficacement, particulièrement pertinente pour les applications plus grandes ou multi-locataires où une bonne organisation des objets importe.