Discussion :

[david_st]

1) En 25 ans de carrière je n'ai jamais rencontré un défenseur des ORM qui connaissait vraiment bien SQL.

2) "Les ORM sont bien pour les requêtes de base."
Ok admettons. Et? Dans la vraie vie d'un vrai système complexe les requêtes de base représente quelle partie du temps de développement par rapport à celui des requêtes complexes?
S'encombrer de la lourdeur d'un ORM pour ça...

3) Les ORM rendent indépendants de la base de données.
Non. Les ORM rendent dépendants de l'ORM !!
Ce qui est bien pire.
Ce qui rend indépendant de la base de données c'est justement SQL.
Si votre couche d'accès est complètement en SQL dans la DB (procédures stockées), vos couches d'accès (qui peuvent être multiples!) sont indépendantes et interchangeables!

3A) Oui mais quid changement de base de données?
Dans la vraie vie changer de base de données se passe moins souvent que le changement de technologie qui s'addressent à la DB.
Et faire passer du SQL d'une DB à l'autre, même si ce n'est pas automatique n'est pas la fin du monde (de DB2 windows à oracle en 2001 à DB2/400 en 2003 à SQL Server en 2016. Sans souci.

Mon expérience, reste assez limitée à MySQL/mariadb et SQLite. et essentiellement derrière du PHP.

quelques points que j’ajouterais :

1) "Les ORM sont bien pour les requêtes de base." => c'est vrai, à condition de bien connaître les ORM, que l'ORM soit bien fournie.

2) Sur l'indépendance de la base de donnée, il faut encore que les bases de données aient les même fonctions. Si pour les fonctions basiques, il y a des équivalences dans dans toutes les bases de données, pour des fonctions plus spécifiques ou elles ne sont pas présentes dans l'ORM (comme right joint avec doctrine) ou elles ne sont pas compatibles avec la DB. (ça m'est déjà arrivé de me faire piéger lors de tests de passer de mariadb à sqlite, d'avoir des erreurs sur sqlite uniquement)

Enfin pour moi, pour bien utiliser sa DB, même avec un ORM, il faut bien connaître sa BD. Du coup, pour bien utiliser un ORM, il faut apprendre DB + ORM =, > 2 * plus d’éléments à apprendre.

Mais il y a quelques points qui obligent à savoir travailler avec ORM :
- la majorité des développement se font avec.
- on trouve sur tous les frameworks (en tout cas le principal) ont un ORM (plus ou moins dédié)
- certains disent que c'est plus sécurisé. (j'aimerais bien que l'on me dise pourquoi, c'est vrai que sur php, msqli c'était mal foutu sur ce point là, mais PDO fait bien le travail) et les entreprises aiment ça.


Du coups, mon avis sur la question, les ORM sont utile dans les cas simples, çà simplifie certain le travail. comme la migration, certain contrôle. Mais complique la tache dés que l'on a quelle chose de complexe à demander.
Le SQL est un langage simple, mais écrire une bonne requête SQL, et de géré une base de donnée, une spécialité.

Alors pour ou contre? je n'est pas d'avis, j'ai une référence à ne pas les utiliser, si je peux. Je trouve que comme ça, on a un meilleure contre sur sa DB.

[BugFactory]

1) En 25 ans de carrière je n'ai jamais rencontré un défenseur des ORM qui connaissait vraiment bien SQL.

Ad personam.

et génère des requêtes supplémentaire

Hibernate génère bien des requêtes supplémentaires, mais pas avec le chargement paresseux. Si on fait le chargement paresseux soi même, il y aura aussi des requêtes supplémentaires. Et si on ne veut pas de requêtes supplémentaires et pas de chargement paresseux, on peut le désactiver. mister3957 a un bon exemple où Hibernate génère des requêtes inutiles (les update). A moins que ce ne soit une critique contre le chargement paresseux lui-même?

Au passages, quelques critiques non justifiées à mon sens.
1. Les ORM ne gèrent pas les transactions.
Si. En tout cas Hibernate le fait. Et avec Spring il suffit d'une annotation sur la méthode.

2. Les ORM introduisent une dépendance vis à vis de l'ORM.
On aura une dépendance vis à vis de l'API utilisée pour envoyer le SQL à la base de données de toute façon.

Et inversement, une critique contre les ORM que je n'ai pas vu : il est difficile d'utiliser un ORM et SQL en parallèle. Il manque des fonctionnalités permettant de prévenir un ORM de modifications externes.

Il y a quelques arguments que je ne comprend même pas, ceux concernant la portabilité. Je n'ai jamais vu, ORM ou pas ORM, d'application où un changement de base de données pourrait se faire en douceur. Une simple concaténation de texte se fait de façon différente entre deux bases différentes. Si on travaille avec des procédures stockées, il faut les réécrire entièrement. Qu'est-ce que l'ORM a à voir la dedans? Sérieusement ce n'est pas une question rhétorique, j'aimerais comprendre.

Ça me rappelle une conversation que j'ai eu il y a quelques années où un développeur se plaignait des performances de XML en me montrant un fichier de 1Go. Normal, ce n'est pas fait pour ça. On n'est pas obligés de faire tout ORM ou tout SQL...

[marc.collin]

Bah non puisque l'on a le contrôle de la requête pour aller chercher ce dont en a besoin et surtout comment. Et ça n'a rien à voir avec le fait de chercher à transformer un schéma relationnel en schéma objet.

c'est le principe de Ibatis, les objets sont basé sur des requêtes au lieu de table

[marc.collin]

Ad personam.
Hibernate génère bien des requêtes supplémentaires, mais pas avec le chargement paresseux. Si on fait le chargement paresseux soi même, il y aura aussi des requêtes supplémentaires. Et si on ne veut pas de requêtes supplémentaires et pas de chargement paresseux, on peut le désactiver. mister3957 a un bon exemple où Hibernate génère des requêtes inutiles (les update). A moins que ce ne soit une critique contre le chargement paresseux lui-même?

si tu mets lazy, lorsque tu voudras accéder à l'élément une autre requête sera faite

[marc.collin]

Valider ce que l'orm génère comme requête.... je n'ai pas compris.
Ce que je montre là c'est la couche controller, ensuite bien entendu tu as ce qui se passe derrière ces fonctions qui fait appel à l'orm, et bien entendu il y a la facilité de traiter les données retournées, notamment pour les relations.

ton orm, au final il génère des requêtes sql?
tu vérifes ce qu'il génère comme requête?

[Sodium]

Donne un exemple concret parce que là ça ne me parle pas...

Vérifier les requêtes, pourquoi ? C'est le job de l'ORM de générer les requêtes qu'on lui demande, et il y a généralement une large communauté open source autour pour s'assurer de la qualité de la librairie.
Et même si la requête récupère des données qu'elle n'est pas censée récupérer, ce n'est pas pour autant que l'on va faire n'importe quoi avec du côté du programme qui utilise cet ORM...

[leulapin]

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 :


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.

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.

Je ne fais que peu de développement et plutôt du maintient en condition de "vieux" logiciels, l'expérience que j'en ai est qu'on ne change quasi jamais de SGBD alors qu'il est courant qu'un logiciel complexe ait été développé sur quatre ou cinq languages ou stacks technologiques différentes suivant les "modes". Quand on fait un changement de SGBD on change de logiciel pour s'adapter aux qualités et défauts du SGBD cible (typiquement en partant de Oracle vers du postges et/ou du cassandra on perd tous les triggers, les vues, les mécanismes de réplication de données ne sont pas les mêmes ni les perfs en écriture/modifications et il faut tout refaire pour obtenir des fonctionnalités équivalentes) donc ORM ou pas, généralement on jette le code précédent. Eventuellement on en sauve des bouts en codant des APIs dessus mais du coup on passe les données dans les appels et le code vintage n'accède plus à la BDD.

Plus globalement le coeur de l'informatique c'est la donnée, pas le code dans l'écrasante majorité des cas, et le langage historique et qui a fait ses preuves pour manipuler de la donnée c'est SQL.

Et SQL n'est pas l'assembleur de la base de donnée mais plus du C si on doit prendre une comparaison selon moi (l'assembleur en gestion de données serait stocker l'information sous forme fichier à plat en redéveloppant toutes les fonctions d'indexations et de parcours des données). Et de la même manière qu'on continue de coder les programmes complexes et nécessitant de la perf en C (typiquement les OS) en faisant très attention à l'architecture des composants codés on devrait continuer avec SQL pour l'informatique de gestion dans l'écrasante majorité des cas.

Les ORMs visent surtout à palier au mauvais niveau en données (conception, manipulation des données...) des devs j'ai l'impression, c'est une mauvaise solution (à un vrai problème néanmoins). Et ça ajoute des bugs dans la gestion du cache de données là où avec du SQL la donnée est enregistrée quand on clique une validation d'écran généralement. Le testeur doit donc non seulement valider ce qu'il voit à l'écran mais ce qui a été enregistré ou pas en BDD. Je pense que juste ce surcroit d'activité en test anihile le gain de temps en dev dans beaucoup de cas.

De ce que j'en vois et sous réserve que ça évolue disruptivement sur les requêtes avec plusieurs jointures, ça ne marchera bien que pour des applis primaires et ne sera rentable que pour des applis qui évoluent très souvent niveau modèle de données. Pour faire du dev ops sur des portails web à la mode agile qui gèrent peu d'informations complexes et délèguent à d'autres le traitement des données collectées c'est parfait, pour tout le reste c'est plutôt superflu je trouve.

[Sodium]

En trois ans à mon nouveau poste, j'ai travaillé sur trois SGBD : MySql, Postgres et Informix. D'ailleurs je suis bien embêté que pratiquement aucun ORM ne supporte informix, d'un autre côté vu sa popularité ce n'est pas étonnant.

[Waldar]

C'est déroutant cette réticence à vouloir apprendre le SQL.

Apprendre des nouveaux langages de programmation c'est courant, et entre Java, Ruby, Python et les centaines d'autres langages c'est quand même un travail d'apprentissage conceptuel et syntaxique qui est loin d'être négligeable. Quand on regarde le CV d'un développeur, on trouve régulièrement de nombreux langages dans sa bannette.

Vous préférez apprendre encore plus de langages spécifiques en rajoutant des ORM au lieu d'apprendre le SQL une fois pour toute, qui reste un langage comme un autre avec ses concepts ensemblistes et sa grammaire.

Certes, les dialectes sont différents d'une base à une autre, mais la logique est toujours la même et le tronc commun est solide et à tendance à grossir avec le temps.
Apprendre les différences entre plusieurs SGBD c'est relativement anecdotique et je le perçois comme un argument paresseux, si on sait ce qu'on cherche en un coup de votre moteur de recherche préféré on trouve. Voyez-ça comme une nouvelle bibliothèque à manipuler.

Est-ce le concept du L4G qui vous effraie ?
Peur de sortir de sa zone de confort ?

Car ceux qui s'y mettent s'en sortent tout à fait honorablement.

[Michel.Priori]

Car ceux qui s'y mettent s'en sortent tout à fait honorablement.

double sens, maître Capello

[Waldar]

Involontaire, bien vu !

[Sodium]

C'est déroutant cette réticence à vouloir apprendre le SQL..

Le problème n'est pas d'apprendre le SQL mais de l'utiliser...

De plus SQL n'est pas un langage de programmation.

[blbird]

Le problème n'est pas d'apprendre le SQL mais de l'utiliser...

De plus SQL n'est pas un langage de programmation.

Je ne vois pas où est le problème? Le HTML aussi n'est pas un langage de programmation, le XML aussi et le JSON aussi. On parle de GraphQL?
J'arrête là où ça suffit?

Sinon il y aussi des langages de programmation orientés autour du SQL, comme le PL-SQL, au cas où.

[marc.collin]

Je ne vois pas où est le problème? Le HTML aussi n'est pas un langage de programmation, le XML aussi et le JSON aussi. On parle de GraphQL?
J'arrête là où ça suffit?

Sinon il y aussi des langages de programmation orientés autour du SQL, comme le PL-SQL, au cas où.

en même tant quand quelqu'un utilise un orm et ne maitrise pas le sql derrière... ça génère de l'emploi pour certain

[Sodium]

Je ne vois pas où est le problème? Le HTML aussi n'est pas un langage de programmation, le XML aussi et le JSON aussi. On parle de GraphQL?
J'arrête là où ça suffit?

Sinon il y aussi des langages de programmation orientés autour du SQL, comme le PL-SQL, au cas où.

C'était une rectification du message précédent. Apprendre plusieurs langage de programmation c'est stimulant. Apprendre des langage de structuration comme le HTML ou langage base de données comme le SQL nettement moins, on le fait parce que l'on en a besoin mais il y a nettement moins de satisfaction intellectuelle derrière.

Je vois venir les "ouiiiiii mais nooooon, le SQL est super intéressant, y a des tas de subtilités, la bonne manière d'écrire les requêtes...."... non, moi ce qui m'intéresse c'est de me concentrer sur la logique et la compréhension du code, pas sur comment parler au mieux à la machine pour qu'elle fasse son taf derrière, ça je considère que c'est son job et pas le miens, tout comme PHP réécrit beaucoup d'instructions en coulisse pour qu'elles soient plus performantes. Surtout que 80% du job avec SQL c'est de programmer la génération des requêtes par concaténation de strings, quel cauchemar, on ne devrait plus avoir à faire ça en 2019...

[blbird]

Surtout que 80% du job avec SQL c'est de programmer la génération des requêtes par concaténation de strings, quel cauchemar, on ne devrait plus avoir à faire ça en 2019...

De toute manière, comme sur les autres sujets où tu n'aimes pas quelque chose (Javascript entre autres), tu vas continuer à nous trouver toutes les excuses du monde pour dire que c'est nul. Genre ici la satisfaction intellectuelle Ce sont tes goûts, ne les généralise pas.

Et quand on creusera un peu, on verra qu'au final c'est parce que tu n'as rien compris à la techno. Comme pour le JS.

[Sodium]

Si la plupart des frameworks possèdent des ORM ce n'est pas par hasard, tout comme le fait qu'il existe tellement de trucs et de machins à greffer sur JavaScript pour pallier ses défauts que ça en fait un monstre difforme dont l'on a envie de débrancher le cordon de survie pour qu'il puisse s'éteindre avec un minimum de dignité. J'avoue par contre sans aucun problème que contrairement au JavaScript, mon niveau en SQL est très médiocre et que je ne fais pas grand-chose pour y remédier. Dans ma boîte il y a des personnes dont le job est en grande partie de pondre des requêtes de plusieurs dizaines de lignes qui vont rassembler des statistiques sur une quinzaine de tables (pour lesquelles il n'y a en généralement qu'une ou deux personnes qui savent à quoi elles servent concrètement) pour sortir des statistiques à la demande à travers des millions de records. Ce n'est pas mon job, moi mon job c'est d'écrire des applications, qu'elles soient propres, avec un minimum de bugs et maintenables.

[blbird]

J'avoue par contre sans aucun problème que contrairement au JavaScript, mon niveau en SQL est très médiocre

Il suffit d'aller voir tes prestations sur les sujets JS pour facilement voir que tu n'y comprend au final rien non plus. Tu y passes un temps fou à y répondre et à montrer à tout le monde ta mauvaise compréhension. C'est juste navrant. A tel point que maintenant tu es bien connu pour ca dans le coin, et tu viens recommencer avec le SQL : tu n'y as jamais rien compris, mais tu viens poster continuellement que c'est nul.

[Sodium]

Allez, on va te dire oui et te donner une tape sur la tête si ça peut te faire plaisir. Maintenant va jouer ailleurs, on est là pour discuter de fond et pas pour faire du bashing de cours de récré.

[blbird]

Allez, on va te dire oui et te donner une tape sur la tête si ça peut te faire plaisir. Maintenant va jouer ailleurs, on est là pour discuter de fond et pas pour faire du bashing de cours de récré.

Mais tu ne peux pas discuter du fond puisque tu ne connais même pas les techno dont on parle.