Les ORM, c’est mal

La fausse route des ORM

Les mapping objets-relationnels sont une erreur. La conception du schéma d’une base de données obéit à des règles différentes de celles de la programmation à objets. Mieux vaut concevoir ses objets avec une approche « métier », je veux dire que les objets devraient être conçus en fonction de ce que le logiciel doit faire et non pas en fonction des règles de normalisation suivies par la base de données.

C’est un peu comme si la boutique devait coupler ses étalages avec les rayons de l’entrepôt. Mais les étalages sont gouvernés par le marketing alors que les entrepôts sont organisés par la logistique. Entre le responsable du marketing et celui de la logistique, qui gagnera ? Lorsque Hibernate ou EclipseLink génère la structure de la base de données au travers d’un code DDL, c’est le marketing qui gère les entrepôts. C’est l’assurance d’une logistique lente et inefficace.

Si l’ORM est une factorisation automatisée du code source, elle est surtout la factorisation du développeur paresseux et elle est loin d’être la plus élégante.

SQL versus ORM : une inversion des bonnes pratiques

Un mapping objet sert à naviguer d’objet en objet. Je sais qu’il est possible de faire autrement mais l’ORM sert à cela. Chaque objet est chargé avec l’intégralité d’une ligne d’une table. Et peu importe que telle colonne ne soit pas utilisée par telle partie du programme, l’objet du mapping chargera toutes les colonnes.

Par comparaison, le SQL sert à sélectionner les valeurs des cellules à utiliser et uniquement celles-là. Le SQL correspond bien au besoin du programmeur car il est rare d’utiliser simultanément toutes les colonnes d’une table dans une même portion du programme.

Certes les ORM proposent tous une solution palliative, une sorte de sous-dialecte SQL avec lequel il devient possible d’extraire des valeurs sans passer par les objets. Il s’agit ici d’une inversion des bonnes pratiques. Bien utiliser un ORM c’est d’abord utiliser les objets du mapping, puis éventuellement pratiquer le sous-dialecte SQL dans les cas qui le justifient. Bien utiliser le SQL c’est, toujours, en une fois, charger les données dont on a besoin, toutes les données dont on a besoin et seulement les données dont on a besoin.

L’élégance et la performance sont les fils conducteurs du SQL. L’ORM n’a que faire de l’élégance et se passerait bien des catastrophes en performance que lui inflige la réalité.

Le débat du SQL versus les ORM porte alors non pas sur ce qu’on peut faire – en vérité on peut faire des objets et des tableaux avec un ORM autant qu’avec du SQL – mais quelles sont les bonnes pratiques en matière de bases de données.

Le cas de PHP

Au-delà des considérations générales, l’utilisation systématique d’objets en PHP a un impact négatif sur les performances. Selon moi cela suffit à changer de perspective par rapport à d’autres langages : on ne devrait pas coder en PHP comme on code en Java. Le cœur de PHP est le tableau associatif PHP. Et ça tombe bien car il est dans la nature du SQL de ramener des tableaux. Alors pour la simplicité, l’élégance et la performance, restons-en à l’essentiel. Le couple « requête SQL – tableau PHP » est le meilleur choix partout où il s’avère suffisant.

4 Responses to Les ORM, c’est mal

  1. Mika says:

    Bonjour,
    Vous écrivez certaines choses inexactes: vous pouvez avec un ORM ne récupérer que les champs désirés d’une table
    Exple:
    public function findAuteurNameById($id){
    return $this->findOne(‘SELECT auteur.nom from auteur WHERE id=?’,(int)$id);
    }

  2. Cpag says:

    C’est vrai, avec un ORM on peut faire une requête SQL. Mais ça ne sert pas à cela. Vous manquez le point que j’ai pourtant mis en titre : l’inversion des bonnes pratiques.

    Si c’est pour écrire des requêtes SQL, un ORM ajoute de la complexité, PDO (ou JDBC) est plus simple.

  3. Mika says:

    Il ne faut pas etre catégorique et bien penser que dans le developpement on peut à certains endroits avoir besoin de performance et un autre endroit non
    L’ORM permet la flexibilité 😉
    J’ai rajouté une partie sur mon article:
    http://blog.developpez.com/ducodeetdulibre/p12224/developpement/orm-or-not-orm-faut-il-les-utiliser

  4. Cpag says:

    “Catégorique” ?
    Ce n’est pas avec un consensus mou entre de bonnes et de moins bonnes pratiques qu’on fait de bons programmes.

Leave a Reply

Your email address will not be published. Required fields are marked *

Mesure anti-spam. Merci de copier le code « vJnvAK » dans le champ ci-dessous :