Faut-il utiliser les ORM ou continuer d'écrire simplement des requêtes SQL ?

Faut-il utiliser les ORM ou continuer d'écrire simplement des requêtes SQL ?
Eli Bendersky donne son avis

L’arrivée des ORM pour les langages de programmation a apporté un certain nombre d’avantages s’agissant de la manipulation et la modification de données dans la construction d’une application. Un ORM (Object Relational Mapping) est un ensemble de librairies qui vous permettent d’interagir d’une manière plus simple avec vos données à travers des objets. Autrement dit, il s’agit d’un programme informatique qui se place en interface entre un programme applicatif et une base de données relationnelle pour simuler une base de données orientée objet. De ce fait, faut-il en utiliser un ou faut-il simplement écrire toutes ses requêtes à la base données avec le langage SQL ?

Il s’agit en effet d’un débat qui s’installe très souvent entre les développeurs. Les ORM sont venus avec pour vocation : la réduction du code à écrire et à maintenir pour l’informaticien qui manipule la base de données depuis son logiciel, l’homogénéité du code objet et l’accélération du temps de développement. Néanmoins, bien que ces avantages semblent très souvent les plus recherchés par les développeurs, les spécialistes des bases de données leur trouvent beaucoup de défauts. On pourrait insinuer que les développeurs y voient surtout une simplification et une accélération de leur temps de développement, mais la bonne pratique des ORM est certainement dans une utilisation modérée et circonstanciée de ces outils.

Selon Eli Bendersky, programmeur et contributeur à l’open source, les ORM, malgré les avantages qu’on peut leur citer, sont limités lorsqu’il s’agit de travailler sur des modèles de bases de données plus complexes que le classique CRUD. Son analyse s’est basée sur une comparaison de l’utilisation du SQL simple et ensuite d’un ORM pour manipuler une base de données d'une application écrite avec le langage de programmation Go. Il a tiré la conclusion selon laquelle l’utilisation ou non d’un ORM dépend des avantages des dépendances supplémentaires en fonction de l’effort. En d’autres termes, cela a-t-il un sens d'implémenter vous-même presque toutes ou toutes les fonctionnalités d'un projet, ou est-il préférable d'utiliser la pléthore de bibliothèques disponibles pour de nombreuses sous-tâches que le projet doit effectuer ?

Pièce jointe 474863

D’après ce qu’explique Bendersky, les avantages des ORM résident principalement dans la réduction du code à écrire, ce qui les laisse avec un lot considérable d’inconvénients. Pour lui, les ORM évitent un codage fastidieux. Ils vous font faire environ 50 % d’économie en code centré sur la base de données, ce qui n’est pas banal et peut faire une réelle différence pour certaines applications. Les autres avantages qu’on peut citer pour les ORM sont plus remarquables avec la plupart des applications simples, mais lorsqu’il s’agit de schémas de bases de données plus complexes ou d’applications avec des niveaux d’abstractions plus avancées, les ORM montrent tout de suite leurs limites.

Par exemple, certains avancent qu'ils ne permettent pas de gérer les requêtes un peu complexes (jointures, groupements), les transactions ou les traitements par lots et parfois, les relations many-to-many sont également difficiles à gérer. Ils créent en plus une forte dépendance à l’outil ORM utilisé. En général, ils causent des problèmes lorsque la base de données n’est pas faite dans les règles de l’art. Dans son cas, Bendersky a utilisé l’ORM Gom pour le langage de programmation Go, qui selon lui présente les mêmes inconvénients. Après son analyse comparative, il a noté les inconvénients suivants liés aux ORM :

• une autre couche à apprendre, avec toutes les particularités, la syntaxe spéciale, les balises magiques, etc. Ceci est principalement un inconvénient si vous êtes déjà familiarisé avec SQL lui-même ;
• même si vous n'avez pas l'habitude d'utiliser SQL, il existe une vaste banque de connaissances et de nombreuses personnes pouvant vous aider à trouver des réponses. Tout ORM est un savoir beaucoup plus obscur que beaucoup ne partagent pas, et vous passerez beaucoup de temps à chercher comment forcer les choses ;
• déboguer les performances des requêtes est un défi, car l’abstraction se trouve à un niveau plus éloigné du métal. Il faut parfois un peu de peaufinage pour que l'ORM génère les requêtes qui vous conviennent, ce qui est frustrant lorsque vous connaissez déjà les requêtes dont vous avez besoin.

Enfin, dit-il, il existe un inconvénient qui ne devient apparent qu'à long terme. Il estime que le SQL reste à peu près constant au fil des ans, mais les ORM sont spécifiques à la langue et tendent également à apparaître et à disparaître tout le temps. Chaque langage populaire dispose d’une grande variété d’ORM. Lorsque vous passez d'une équipe/entreprise/projet à un autre, vous pouvez être amené à changer de fournisseur, ce qui constitue un fardeau mental supplémentaire. Ou vous pouvez changer complètement de langue. Pour lui, le SQL est une couche beaucoup plus stable qui vous accompagne dans vos équipes/langages/projets et ceci, peu importe les circonstances.

Enfin, il finit en réitérant que l’attrait le plus important des ORM est la réduction du code passe-partout, mais mis à part cela, dit-il, il existe de nombreux inconvénients à utiliser un ORM. Selon lui, les langages de programmation comme le langage Go font aujourd’hui l’effort de proposer un bon interfaçage avec le SQL. Il faudrait donc éviter les dépendances inutiles aux ORM ou à d’autres bibliothèques au risque de perdre la fluidité voulue pour son projet. « Je ne pense pas qu’un ORM me soit utile dans un langage comme Go, qui possède déjà une bonne interface SQL, principalement portable sur les bases de données. Je préférerais passer un peu plus de temps à taper mes requêtes, mais cela me fera gagner en performance après. Mes requêtes seront optimisées et, plus important encore, le débogage sera plus facile à effectuer », a-t-il déclaré.

De même, selon certains, les gains de productivité (du moins au tout début du développement) avec l’utilisation d’un ORM sont indéniables. Par contre, a écrit l’un d’entre eux, « ce que j'ai toujours recherché, ce sont des frameworks qui vous donnent un ORM mais rendent aussi les requêtes de bas niveau très faciles, normalement à travers un constructeur de requêtes et vous permettant de passer d'un niveau d'abstraction à un autre. Si je devais choisir, je préfère les bibliothèques qui vous donnent d’abord le niveau le plus bas d’abstractions, puis s’appuient sur celles-ci pour offrir une approche ORM basée sur la programmation orientée objet (ce à quoi, selon moi, la plupart des gens pensent quand on dit “ORM”) ». Il cite TypeORM comme l’une des meilleures bibliothèques qu’il a utilisées.

Mais dans le même temps, un autre indique que TypeORM avait été écrit par des personnes qui ne connaissaient pas vraiment le SQL. Pour lui, les ORM sont excellents pour les tâches répétitives, en particulier lorsqu'ils sont intégrés à des frameworks. Cependant, dit-il, la présence d’un ORM peut empêcher le plus souvent d'accéder aux aspects les plus avancés d’une base de données.

Source : Billet de blog

Et vous ?

:fleche: Quel est votre avis sur le sujet ?
:fleche: Devrait-on continuer d'utiliser les ORM, selon vous ? Pourquoi ?

Voir aussi

:fleche: Prisma, un outil ORM pour le développement des applications modernes. Pourra-t-il remplacer les outils ORM traditionnels ?

:fleche: L'ORM serait-il une « grosse erreur » ? Selon un développeur, « l'ORM est un anti-pattern qui ne devrait pas exister »

:fleche: « ORM or not ORM » : faut-il les utiliser ou continuer d'écrire simplement des requêtes SQL ?

Pour moi les ORM excellent dans les points suivants :

• Opération d'écriture => pas de SQL à faire nous-même => gros gain de temps.
• Cache : le cache transactionnel permet de séparer les développements tout en évitant le double requêtage de certain élément s'il sont déjà chargés par l'ORM

Les points à surveiller sont les suivants :

• Ne pas vouloir charger trop de données d'un coup ou pas assez, et donc ne pas tirer parti du cache ou faire exploser la RAM.
• Cache inter-transaction : faire attention avec cela.
• Recherche : on peut faire des choses relativement puissantes, surtout pour aller de paire avec des filtrages typiques d'écran de recherche.

Je mets les éléments suivants à part :

• Performance de base (N+1 select, traitement prs batch typiquement) => manque de compétence (ou d'un guide) du développeur sur l'outil plutôt qu'autre chose.
• Requêtage complexe : je ne pense pas que les ORM avaient prévu (et c'est toujours le cas) de remplacer le SQL dans tous les cas d'utilisation. Il faut donc faire preuve de jugement et passer au SQL quand c'est nécessaire. Par exemple, les requêtes récursives sont possibles en SQL, autant s'en servir s'il le faut.
• En Java par exemple certains éléments d'ORM ne sont pas 100% compatibles sur les SGBD : il s'agit de problème de Driver JDBC, pas des ORM.

Avouons que, la plupart du temps, le problème ne vient pas de l'outil, mais de la méthode.
Et pour être plus exact de la qualité de ce comment la "conception" est menée.

Pour avoir un ORM il faut un modèle objet.
Or, comment est conçu ce modèle ?

La plupart du temps : "à l'arrache"

Quelle est la portée du modèle ?

La plupart du temps : "limitée au développement"

Franchement quand on a dépassé ça, on a franchi un grand pas.

Je suis sidéré par le silence (ou par les tentatives de détournement d'attention) lorsqu'on demande à consulter les documents "conceptuels" (diagrammes UML, MCD, ...)
Un peu comme le cahier des charges ; tout le monde en parle, personne ne l'a lu ;)

La doxa du moment est de développer toujours, et encore, plus vite.
Tout faire "pour hier", sans répits, sans documentation, sans partages, sans contradictions, ne peut pas aller dans le sens de la qualité.

Comme déjà indiqué ci-dessus, il faut savoir prendre différents outils selon les circonstances :
- Mapping ORM pour les opérations CRUD de base, pour ne pas créer de requêtes basiques, qui n'apportent pas de valeur ajoutée, et faciliter les évolutions des modèles de données,
- requêtes sur-mesure pour tout ce qui ressort des requêtes un peu évoluées, avec optimisation si besoin.

ça nécessite juste les compétences nécessaires pour ce métier, et savoir choisir les bons outils (dédicace à un de mes anciens formateurs)

Je travaille sur le maintien en conditions opérationnelles d'un logiciel ancien. Tellement ancien que l'archivage automatique est en PLS depuis 5 ans. Il y a une couche logicielle entre la BDD et le produit. Le nombre de données à archiver est tellement important qu'à chaque tentative de purge, la couche logicielle fait un memory full. J'ai donc demandé à mon équipe de développement de ré-écrire la fonction de purge en pure SQL. Voilà...

Utiliser un ORM, pourquoi pas ? Mais surtout commencer par former correctement les développeurs Java à l'écriture des requêtes et au fonctionnement sous-jacent d'un SGBD.
Non, ce n'est pas plus simple de filtrer les lignes dans le code Java. Ca encombre juste inutilement le réseau.
Non, ce n'est pas plus efficace d'effectuer les vérifications de validité dans le code Java. Ca permet juste de laisser la capacité d'enregistrer des données invalides dans la base de données.
Non, ce n'est pas utile de calculer des totaux dans le code Java pour les enregistrer dans la table. C'est seulement une manière de riquer à terme d'avoir une information calculée stockée différente du contenu réel des données.

Citation:

---

On calcule l'âge du prospect au moment de son enregistrement dans la base. Ca ira plus vite que de le calculer à chaque fois qu'on en a besoin...

---

:ptdr:

Le souci, n'est pas vraiment l'utilisation d'un orm, mais bien la conceptualisation de la db (MCD, MLD).
Car si l'application deviendra obsolète les données seront toujours utile.
Je migre une source de données de 1998 et je pleure tous les jours

SQL est un reliquat d'une autre époque et il est très compliqué de faire un code compréhensible et réutilisable. Donc ORM à 100%, il serait temps que les bases de données évoluent en rentrent dans le 21e siècle.

Citation:

---

Envoyé par Sodium

SQL est un reliquat d'une autre époque et il est très compliqué de faire un code compréhensible et réutilisable. Donc ORM à 100%, il serait temps que les bases de données évoluent en rentrent dans le 21e siècle.

---

Sauf que les ORM font des requêtes SQL

Tout comme le code devient du binaire, personnellement je préfère utiliser un code propre et compréhensible plutôt que du binaire ;)

Sql est un peu l'assembleur des BDDs tout comme JavaScript est l'assembleur du web côté client.

Voilà plus de 5 ans que je suis "abonné" à developpez.net sans jamais m'être inscrit(**t'aurais du le rester)... Mais les récents post et leurs commentaires associés suscitent un accueil de moins en moins "chaleureux" de ma part.

Je vais commencer par un jugement de valeur sur l'avis de M. Eli Bendersky:

Lorsque je constate que les langages de programmation et ORMs choisis comme base de comparaison et/ou fer de lance de la famille des ORMs sont respectivement Go + TypeScript et Gom + TypeORM, alors je me demande si je dois gerber ou raler.
Voici plus d'un an que je code en TypeScript côté Back(NestJS), et je peux vous dire que typeorm est mieux que l'éditeur de requête SQL basique(knexJS), indépendamment de la complexité du système; cependant, mon expérience avec l'ORM de django est à des années lumières du reste en terme de plaisir d'utilisation et d'efficacité. J'ai le même retour venant des utilisateurs(mes amis & collègues) d'Active Record(Ruby - Rail), ainsi que que des utilisateurs d'Entity Framework.

Comme d'habitude, dans mon entourage proche, les ORMs Java marchent bien, mais sont très critiqués pour leur lourdeur.

En outre, lors du test de prisma(orm extrêment prométeur) avec Go, j'ai eu l'impression de traîner un boulet :traine:.
Mon opinion sur Go est assez catégorique et peut-être biaisée; écrire du code business avec Go c'est presque pareil que de le faire en C.

Enfin, un jugement plus factuel et technique:

Avoir des connaissances sur la base de données choisie pour le développement de votre application:
- Relationnelle? Orienté document? Graphe? Entrepôt? Qu'est ce qui correspond le mieux à vos besoins?
- Comprendre la notion de transaction.
- Développer le bon sens dans la construction des requêtes(optimiser en fonctions de son modèle de données, utiliser correctement les alias...).
- savoir si vos requêtes sont optimisées automatiquement par le moteur de calcul de l'ORM.
- connaître les stratégies de caching de requêtes proposées par l'ORM.
- savoir quel driver vous utilisez: est-ce qu'il génère des requêtes textuelles destinées à être réinterprétées par l'engine de la DB ou bien des requêtes sérialisées...

Orm ou pas, l'idée est:
- d'en apprendre toujours plus sur les outils mis à notre disposition,
- pour produire des solutions de qualité à nos problèmes (CRUD, traitement, maladie, mariage, etc ...)

Ecrire directement des requêtes SQL sans passer par un ORM pose deux gros problèmes :

• Chaque SGBD a son propre dialecte non standard de SQL.
• Assembler des morceaux de requêtes SQL n'est pas pratique.

Comme exemple d'ORM, prenons celui du framework Django de Python.

Extrait de la documentation :

Citation:

---

Example:

Code:

---

Entry.objects.get(title__iregex=r'^(an?|the) +')

---

SQL equivalents:

Code:

---

1 2 3 4 5 6 7

SELECT ... WHERE title REGEXP '^(an?|the) +'; -- MySQL   SELECT ... WHERE REGEXP_LIKE(title, '^(an?|the) +', 'i'); -- Oracle   SELECT ... WHERE title ~* '^(an?|the) +'; -- PostgreSQL   SELECT ... WHERE title REGEXP '(?i)^(an?|the) +'; -- SQLite

---

---

Ici, passer par un ORM permet de changer plus facilement de SGBD, car il n'y a pas besoin de réécrire la requête.

Autre exemple :

Code:

---

Entry.objects.filter(pub_date__year=2005).order_by('-pub_date', 'headline')

---

Dans le code ci-dessus, Entry.objects est un objet de type QuerySet.
La méthode QuerySet.filter retourne un nouveau QuerySet qui contient un filtre en plus.
La méthode QuerySet.order_by retourne un nouveau QuerySet qui contient un tri en plus.
C'est uniquement lorsqu'on essaie de parcourir le QuerySet final que ce dernier est converti en requête SQL et que cette dernière est exécutée.
Du coup, on peut voir la classe QuerySet comme un morceau de requête SQL que l'on peut compléter au fur et à mesure en appelant des méthodes de la classe QuerySet. On peut alors faire ce genre de chose dans le code Python :

Code:

---

1 2 3 4 5 6

query_set = Entry.objects if condition_1: query_set = query_set.filter(pub_date__year=2005) if condition_2: query_set = query_set.order_by('-pub_date', 'headline')

---

Cependant, lorsqu'on a besoin de fonctionnalités avancées qui ne sont pas supportées par l'ORM de Django, il faut écrire les requêtes SQL à la main.

Sodium a raison de dire que SQL est un reliquat d'une autre époque et que c'est un peu l'assembleur des SGBD.
Il faudrait que les ORM continuent de se développer pour qu'on ait de moins en moins souvent besoin d'écrire directement des requêtes SQL.

Citation:

---

Envoyé par Pyramidev

Sodium a raison de dire que SQL est un reliquat d'une autre époque et que c'est un peu l'assembleur des SGBD.
Il faudrait que les ORM continuent de se développer pour qu'on ait de moins en moins souvent besoin d'écrire directement des requêtes SQL.

---

Ce sont surtout les SGBD qui devraient évoluer et entrer dans la modernité.
Il paraît que les bdd objet y en a qui ont essayé ils ont eu des problèmes.
Mais ce n'est pas parce qu'ils se sont plantés qu'il ne faut pas continuer d'avancer. En réfléchissant comme ça on en serait encore à coder avec des cartes poinçonnées.

Citation:

---

Envoyé par Pyramidev

Ici, passer par un ORM permet de changer plus facilement de SGBD, car il n'y a pas besoin de réécrire la requête.

---

Ha le vieux fantasme de changer de moteur de DB à la volée.
Si cela est vrai pour des outils de gestion (Drupal, CMS ou autre), c'est à dire des outils qui se veut généraliste.
Cela est nettement moins vrais pour des outils spécialisé.

L'ORM apporte une facilité d'utilisation, une indépendance par rapport à la BD sous-jacente et un modèle objet. Par contre, cela se fait au détriment de la performance: l'ORM crée une requête SQL sur laquelle on n'a pas de contrôle, si elle n'est pas optimisée l'exécution s'en ressentira. De plus une requête SQL retourne une ligne qui est mappée dans des variables, l'ORM rajoutera en plus la création d'un objet pour recevoir les données..
Si votre objectif est la performance (traitement d'un grand jeu de données), il est préférable de rester sur du SQL: vous aurez plus de points de contrôle (notamment avec le plan d'exécution)... Si votre objectif est de ne pas se soucier de la BD et d'avoir une maintenance simplifiée, l'ORM présente des avantages indéniables...

ca fait quelques projets from scrap que j'utilise jpa avec hivernate, le prochain n'utilisera aucun orm.

Je suis partout de 0 il y a environ 5 ans niveau orm et je trouve que le gain n'est pas si énorme en terme d'économie de temps.

De tout façon faut tout valider les requêtes qui sont généré derrière, faire les optimisations.
Selon le cas, tu veux qu'une structure objet soit fetché... afin de ne pas avoir le problème des requête n+1.

Il y a quand même beaucoup de bug, suffit de voir hibernate, les cas complexes ne sont pas toujours possible et nécessite de faire du natif.

Ils ne supporte pas toujours des framework dit reactive.

Je pense utilisé Spring Data JDBC ou bien R2DBC (pour le reactive) qui permet de s'affranchir une partie des requêtes à créer

La réponse n'est pas binaire.

L'ORM est portable entre SGBD (apres est ce que l'on change souvent de SGBD ?), simplifie grandement la maintenance et les accès. En gros, il faut pour vous le travail d'accès à la base.

MAIS, ce n'est pas performant: surcharge et pas de possiblité d'utiliser toutes les fonctionnalités du SQL (par exemple: le insert or update de mysql avec linq).

Le SQL directement est clairement plus performance mais c'est la maintenance qui est beaucoup plus compliquée et le code appelant que l'on doit ecrire pour chaque requete.

J'ai eu plusieurs cas avec des sites internet. On gagne quelques ms en SQL direct (multiplié par le nombre de requete, c'est enorme). Et en SEO, le temps de reponse est important.
Le gain est aussi important quand on doit gérer beaucoup de donnée.

Apres, j'ai vu aussi un problème developpeur: l'orm simplifie l'acces du coup, le dev ne prend plus la peine de recuperer juste ce qu'il a besoin. On recupere toutes les données de la row alors que l'on a besoin qu'une date par exemple.

La librairie dapper a fait des tests de perfo: https://github.com/StackExchange/Dapper pour ceux que cela interresse. On voit clairement que le SQL direct est gagnant en perf.

En résumé, pour des petites projets ne demandant pas des reponses en quelques ms, utilisé l'ORM sinon utiliser SQL directement (au moins en partie).

Sinon, je suis tombé récement sur un projet intermédiaire: sqlwrapper (C#). Cela genere du code à partir de la requete SQL automatiquement.
En gros, vous écrivez votre requete dans un fichier text et automatiquement il genere le code C# appelant avec les paramètres. Apres test, cela marchotte mais c'est prometteur car cela simplifirait grandement l'utilisation du SQL directement.

Citation:

---

Envoyé par marc.collin

Je suis partout de 0 il y a environ 5 ans niveau orm et je trouve que le gain n'est pas si énorme en terme d'économie de temps.

---

Si tu ne trouves pas que le gain de temps est conséquent, c'est probablement que ton code derrière n'est pas bien factorisé.

Personnellement dans doctrine je travaille avec des minis fonctions dans les repository qui servent à constituer les requêtes de manière chaîanable.

Ainsi si j'ai besoin de récurer mes produits par ordre alphabétique je fais : $products = $repo->initQuery->getProducts()->sortByName()->fetchAll();
Si ailleurs j'ai besoin d'un seul produit : $product = $repo->initQuery()->getProducts()->byId(10)->fetch();
Et je peux imaginer d'avoir besoin d'uniquement de ceux appartenant à au moins 3 catégories, puis les trier par nombre de catégories tiens : $repo->initQuery->getProducts()->whereHasCatgoriesCount(3)->sortByCategoriesCount()->fetchAll();

C'est clair, concis, réutilisable partout, on y greffe très facilement autant de choses que l'on veut et autant de variantes que nécessaires sans encombrer le controller de code inutile.

Citation:

---

Envoyé par Sodium

Si tu ne trouves pas que le gain de temps est conséquent, c'est probablement que ton code derrière n'est pas bien factorisé.

---

On en revient à la méthode : si les bases ne sont pas là .. les technos qui permettent d'aller plus vite nous poussent dans le mur avec d'autant plus de force.

Investir du temps sur un ORM, sur du SQL, sur une méthode, ... c'est toujours y passer du temps ; temps non directement productif.
Faut aller plus vite.

Si l'objectif est d'étaler de la peinture au mur, arrose le à coup de seau de peinture = objectif atteint.

Citation:

---

Envoyé par Sodium

Si tu ne trouves pas que le gain de temps est conséquent, c'est probablement que ton code derrière n'est pas bien factorisé.

---

il est question ici de valider ce que le orm génère comme requête et non de factorisation.

Citation:

---

Envoyé par Sodium

Personnellement dans doctrine je travaille avec des minis fonctions dans les repository qui servent à constituer les requêtes de manière chaîanable.

Ainsi si j'ai besoin de récurer mes produits par ordre alphabétique je fais : $products = $repo->initQuery->getProducts()->sortByName()->fetchAll();
Si ailleurs j'ai besoin d'un seul produit : $product = $repo->initQuery()->getProducts()->byId(10)->fetch();
Et je peux imaginer d'avoir besoin d'uniquement de ceux appartenant à au moins 3 catégories, puis les trier par nombre de catégories tiens : $repo->initQuery->getProducts()->whereHasCatgoriesCount(3)->sortByCategoriesCount()->fetchAll();

C'est clair, concis, réutilisable partout, on y greffe très facilement autant de choses que l'on veut et autant de variantes que nécessaires sans encombrer le controller de code inutile.

---

Pas besoin d'un orm pour faire ça... spring-data en est la preuve