L’auteur explique comment optimiser Doctrine ORM pour éviter non seulement le problème classique du N+1, où l’accès aux relations dans une boucle génère des dizaines voire centaines de requêtes, mais aussi le piège du produit cartésien qui survient lorsqu’on tente de tout charger en une seule requête avec de nombreux LEFT JOIN : bien que n’affichant qu’une requête dans le profiler, ce type de jointures multiplie les lignes SQL retournées (chaque combinaison de collections), ralentit la page et surcharge Doctrine lors de l’hydratation des objets. La solution proposée repose sur une hydratation en plusieurs étapes en chargeant d’abord les entités principales avec une relation, puis en « primeant » séparément les autres relations via des requêtes successives utilisant l’Identity Map de Doctrine, ce qui aboutit à quelques requêtes légères et prévisibles sans explosion des résultats.
L’article défend l’importance des bases de données relationnelles comme exemple de « boring technology » sous-estimée, soulignant que malgré leur large utilisation pour stocker des données, beaucoup de développeurs ne maîtrisent plus le SQL ni les fonctionnalités avancées des SGBD, ce qui se révèle problématique quand les charges augmentent et que les performances chutent ; il ajoute que les ORM sont utiles mais doivent être bien compris pour optimiser les requêtes et exploiter pleinement des concepts comme vues, index ou requêtes récursives afin de bâtir des applications robustes sans multiplier inutilement les technologies.
L'auteur partage son expérience d'optimisation de traitement de données pour son blog, passant de plusieurs heures à quelques minutes. Il explique son architecture basée sur l'event sourcing pour analyser les visites, stockées dans une base de données et traitées par différents projecteurs. Face à un problème de performance lors de la reprocessus de 11 millions de lignes, il décrit son approche pour améliorer les performances, en commençant par établir une ligne de base de 30 événements par seconde.
Cet article explique pourquoi Doctrine ORM sauvegarde les modifications des entités même sans appeler la méthode persist(). Le mécanisme clé est le "dirty checking" : Doctrine suit les entités gérées (chargées depuis la base de données), compare leurs valeurs actuelles avec une copie initiale, et génère des requêtes SQL uniquement pour les champs modifiés lors de l'appel à flush(). La méthode persist() n'est nécessaire que pour les nouvelles entités.
Tout est dans le titre
3 conférences résumées :
- L’aventure d’une requête HTTP — ou le chemin de la vie des devs -> il y a tant de concepts derrière que le conférencier insiste sur la modestie à avoir et sur le fait de se reposer sur ses coéquipiers
- Et si on repensait les ORMs ? -> présentation de l'ORM Format, un concurrent de Doctrine / Eloquent basé sur d'autres concepts (très bien fait pour le DDD)
- Webhooks at scale -> Le speaker présente le concept de Circuit Breaker
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'auteur donne son opinion sur l'intérêt ou non de découpler totalement les entités de l'ORM / Framework / ... Pour résumer, il faut que le modèle puisse être testé "en isolation" (sans base de données) mais y mettre des annotations (par exemple, Doctrine) n'est pas contre indiqué -> cela ne rend pas le modèle moins testable.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre... mais les principes exposés ici s'appliquent à d'autres ORM comme Doctrine (a priori ?)
présentation de l'ORM Eloquent (utilisable avec le framework PHP Laravel)