Bilan · Partie 3
Bilan
L'étude de cas relie tout : un schéma sérieux (clés composites, unicités, index), des fonctions et procédures qui portent la logique (score, niveau, lot), des triggers pour contrôler et tracer, des transactions pour ne jamais laisser un lot à moitié écrit, une sauvegarde testée qui restaure aussi la logique, et un dashboard alimenté par des requêtes analytiques (GROUP BY, vues, window functions).
| Besoin du cas | Mécanisme |
|---|---|
| Empêcher les doublons | contrainte d'unicité composite (source, identifiant externe) |
| Calculer la pertinence | fonction de score (CASE en SQLite) |
| Contrôler avant écriture | trigger BEFORE |
| Tracer après écriture | trigger AFTER + log métier |
| Lot tout ou rien | BEGIN / COMMIT / ROLLBACK |
| Ne pas perdre les données | dump, rotation, test de restauration |
| Piloter | vues et requêtes de dashboard |
Vérifie que tu as compris
Quel mécanisme répond au besoin « un lot invalide ne doit laisser aucune trace dans les données » ?