Énumérations, tables de référence et argent
IntermédiaireTrois choix de modélisation qui reviennent dans presque chaque schéma.
Statuts : enum, CHECK ou table de référence ?#
| Option | Avantage | Inconvénient |
|---|---|---|
Type enum | Compact, typé | Ajouter une valeur est simple ; en retirer ou réordonner est pénible |
text + CHECK (... IN (...)) | Souple, migrations faciles | Liste dupliquée dans la contrainte |
| Table de référence + clé étrangère | Ajout de valeurs sans migration DDL, métadonnées (libellé, ordre) | Une jointure de plus |
Astuce : pour des valeurs qui évoluent avec le métier (statuts, types), préférez une table de référence. Pour un ensemble vraiment stable (
'M'/'F',true/false),CHECKsuffit.
L'argent#
prix numeric(12, 2) -- exact, pratique
prix_cents bigint -- entiers : simple et sans ambiguïté
prix_float double precision -- NE JAMAIS FAIRE : 0.1 + 0.2 <> 0.3
Stockez aussi la devise (char(3)) si plusieurs sont possibles, et faites les arrondis à un seul endroit.
Suppression logique#
ALTER TABLE clients ADD COLUMN supprime_le timestamptz;
-- Toutes les requêtes doivent filtrer : WHERE supprime_le IS NULL
-- Un index partiel garde les performances : CREATE INDEX ... WHERE supprime_le IS NULL
Piège : la suppression logique complique chaque requête et chaque contrainte d'unicité (utilisez des index uniques partiels). Ne l'adoptez que si vous avez un vrai besoin d'historique ou de restauration, pas par réflexe.