SQL

Le SQL bien fait est souvent ce qui sépare une app qui tient la charge d’une qui s’effondre. Je modélise toujours en SQL pur d’abord, puis je mappe avec Doctrine seulement quand c’est justifié.

#Mes pratiques SQL

• Modélisation 3NF par défaut, dénormalisation ciblée (et documentée) quand les requêtes l’exigent.
• Index composites pensés depuis le query plan, pas après les ralentissements en prod.
• EXPLAIN ANALYZE systématique sur toute requête qui touche >10k lignes.
• Transactions courtes, isolation comprise (READ COMMITTED, SERIALIZABLE selon le cas).
• Migrations versionnées via Doctrine Migrations (PHP) ou Liquibase / Sqitch sur les projets non-Symfony.

#Moteurs

• MySQL 8 / 9 : le défaut sur o2switch et la plupart des mutualisés. JSON natif, CTE, window functions.
• PostgreSQL 16 sur les projets exigeants (full-text search, JSONB indexé, types personnalisés).
• SQLite pour les tests d’intégration rapides et le prototypage.

#Côté Doctrine

DQL pour les requêtes typées, raw SQL via Connection::executeQuery() quand DQL devient une contorsion. Pas de Repository::findAll() en prod, jamais.

Besoin d’une base bien modélisée et performante ? Demande un devis.