Colonnes générées, triggers et fonctions

Certaines règles sont mieux placées dans la base : calculs dérivés, audit, invariants qui doivent tenir quel que soit l'appelant.

Colonnes générées#

ALTER TABLE lignes_commande
    ADD COLUMN montant numeric(12, 2)
    GENERATED ALWAYS AS (quantite * prix_unitaire) STORED;

Toujours cohérente avec ses sources, indexable, jamais écrite à la main.

Triggers#

CREATE FUNCTION maj_modifie_le() RETURNS trigger AS $$
BEGIN
    NEW.modifie_le := now();
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER utilisateurs_modifie_le
    BEFORE UPDATE ON utilisateurs
    FOR EACH ROW EXECUTE FUNCTION maj_modifie_le();

Audit et notifications#

• Un trigger AFTER peut écrire dans une table d'historique.
• LISTEN / NOTIFY transmet un message léger aux clients connectés (invalidation de cache, réveil d'un worker) : sans garantie de livraison si personne n'écoute.

Piège : la logique dans les triggers est invisible pour l'application et difficile à tester ou déboguer. Réservez-les aux invariants et à l'audit ; gardez la logique métier dans le code applicatif.