Discussion :

[Bill Fassinou]

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 ?

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 ?

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

Voir aussi

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

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

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

[walfrat]

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.

[Michel.Priori]

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é.

[Cincinnatus]

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)

[CaptainDangeax]

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à...

[al1_24]

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.

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...

[MaitrePylos]

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

[wallas00]

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 .
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 ...)

[Pyramidev]

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 :

Example:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

SQL equivalents:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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.

[MaitrePylos]

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

[Sodium]

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.

[pachot]

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.

Un peu de hiérarchie des languages de programmation:

L1G: Language de 1ère génération: binaire
L2G: Language de 2ème génération: assembleur
L3G: Language de 3ème génération: langage procédural (Java par exemple)
L4G: Language de 4ème génération: langage déclaratif (SQL)

De même, les structures hiérarchiques (Object, XML, JSON,...) sont les plus vieilles (IMS) et ont été supplantées par le relationnel (SQL) il y a longtemps. Revenir à ces structures en leur mettant de nouveaux noms et de nouvelles syntaxe n'a rien de plus moderne.

ORM, Object,... tout ça c'est un retour en arrière pour les structures de données s'un système d'information. C'est ça qui est vieux. SQL est un language au dessus des languages procéduraux: le SQL est compilé par l’optimiseur en language procédural (le plan d'exécution). L'optimiseur SQL passed de L4G à L3G tout comme le compilateur Java passe de L3G à L2G.

Si on n'aime pas las syntaxe SQL, il y a des DSL qui génèrent du SQL, mais en restant au même niveau (L4G déclaratif), comme https://www.jooq.org/

[StringBuilder]

J'avoue ne pas comprendre quand certains préconisent un ORM pour faire du CRUD et des PS pour faire les traitements.

Rien de plus simple que le CRUD… même un pogo qui a appris le SQL avec MySQL saura écrire les requêtes.
Quel intérêt de passer par un ORM ?

Ensuite, l'ORM, dès qu'on va commencer à faire des traitements plus complexes, va être à la rue.
Et dans tous les cas, si le DBA et les devs "BDD" ont fait leur boulot, il y aura toutes les vues et PS nécessaires pour répondre à toutes les problématiques.

Vous semblez oublier qu'avec votre ORM, si le modèle de données évolue (split d'une table en deux, modification d'une clé primaire, passage d'une colonne d'énumération en une table de référence, etc.) il faut repasser dans tous le code, et tout recompiler… dommage quand même quand il s'agit simplement de faire un CRUD sur une table !
Si vous travaillez avec des vues, une simple évolution de ces dernières permettra de ne rien toucher au code applicatif ! Très pratique si vous avez plusieurs applications impactées par la modification de la base…

Un petit rappel de cet article sur le sujet :
https://www.developpez.net/forums/bl...-base-donnees/

[deltree]

...
Si on n'aime pas las syntaxe SQL, il y a des DSL qui génèrent du SQL, mais en restant au même niveau (L4G déclaratif), comme https://www.jooq.org/

Alors désolé mais jooq, s'il y a bien un truc que je ne conseillerais pas c'est ça! (et j'ai pratiqué) c'est un wrapper de SQL qui n'apporte rien de plus que SQL, autant coder en pur SQL.

Pou moi soit on fait du SQL sans surcouche au langage, et on peut utiliser myBatis qui permet quand même de "ranger" ses requetes SQL et de supprimer la partie fastidieuse de fetch à la main, soit on préfère le tout objet pour les raisons évoquées par ailleurs et on passe en JPA, qui est normé, permet d'utiliser Hibernate, Eclipse link ou autre.
Ne pas oublier aussi JTA qui apporte la partie transactionelle.

[SQLpro]

SQL est un reliquat d'une autre époque et il est très compliqué de faire un code compréhensible et réutilisable.

C'est peut être votre cerveau qui est obsolète !
Mais c'est surtout un manque de formation qui est à l'origine du rejet du SQL auprès de développeurs...
Or le SQL est bien entré dans le 21e siècle depuis longtemps avec le norme SQL:1999 permettant les types objets, le récursif, les déclencheurs, les fonctions fenêtrées, etc.
Le NoSQL qui voulait d'abord dire "Plus de SQL" est passé au N O SQL c'est à dire "Not Only SQL" puis maintenant au New SQL !

Donc ORM à 100%, il serait temps que les bases de données évoluent en rentrent dans le 21e siècle.

N'oubliez jamais ce que disait Ted Neward : "ORM is the Vietnam of computer sicience". Autrement dit tout le monde s’embourbera dans cette merde et y pataugeras longtemps...

Une de mes études, d'il y a plus de 10 ans et toujours d'actualité :
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

A +

[pboulanger]

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...

[max2148]

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.

[marc.collin]

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.

pour les fonctions les plus basiques oui...

chaque bd a des types de données différentes et des fonctionnalités différentes qui ne sont pas nécessaire pris en compte par un orm, par exemple un hstore de postgres n'existe pas dans les autres bd... pour pouvoir l'utiliser dans jpa, beaucoup de code a été nécessaire pour que ça puisse fonctionner

[SQLpro]

… par exemple un hstore de postgres n'existe pas dans les autres bd...

Si, dans SQL Server via les tables In Memory et l'indexation ColumnStore….

A +