Envoyé par
StringBuilder
J'ai commencé l'informatique il y a maintenant 20 ans, à l'époque où les ORM étaient tout sauf monnaie courante.
A vrai dire, j'ai dû attendre au moins 10 ans avant de voir les premiers projets utilisant des ORM à proprement parler.
Ensuite, est arrivée l'époque de la grande mode du Java et du XML… Ces solutions ont été réécrites, et on s'est retrouvé avec des fermes de 10 serveurs de quadri processeurs xeon 1 GHz avec 8 Go de RAM chacuns pour absorbler la même charge avec des temps de réponse décuplés (plus de 5 seconde de temps de réaction).
La raison ? Simple : là où chaque écran déclenchait 2 ou 3 requêtes SQL convenablement écrites, maintenant on a droit à des dizaines, si ce n'est parfois des centaines de requêtes, parfois complètement débiles et redondantes. On a beau passer à des réseaux 10 GBps, le temps de latence de 10 requêtes sur une machine ultra moderne est toujours plus grand d'une seule sur un vieux pentium 200 en 10 MBps. C'est comme ça.
Côté développement avec des ORM, j'en ai pour ainsi dire pas fait. A chaque fois que j'ai commencé à écrire des débuts de programmes, je me suis rendu à l'évidence après quelques heures : l'empilement des couches, et l'abstraction totale de la base de donnée produit des requêtes multiples et inutiles. Au mieux, on va pallier une partie des défauts en mettant en place du cache applicatif, qui va bouffer 4 Go de RAM juste pour afficher une page de temps en temps.
-- Edit : ah, oui, et autant mon expérience des ORM en tant que DEV ne va pas chercher bien loin, autant mon expérience des développeurs qui n'ont aucune idée de ce qu'est une base de donnée et le SQL s'est peaufinée sur 20 ans d'expérience…
Et visiblement, malgré la présence d'un ORM, une méconnaissance de base de ce qui se passe en base de données ne résout aucun des problèmes que j'ai pu constater.
1/ Faire 1 lot de 1 requête : je ne sais même pas si un ORM est capable de lancer plusieurs requêtes dans un même lot. Cela permet pourtant d'échanger avec le serveur en une seule fois.
2/ Faire 1 requête par information unitaire : à l'image de la réponse de deltree ci-dessous, cette pratique, pourtant cause d'un encombrement conséquent du SGBD est monaie courante.
3/ Faire des requêtes dans des boucles pour déterminer des données relatives à un résultat intermédiaire : si on ne demande pas à l'ORM de le faire, il ne fera pas la jointure, et ne saura en aucun cas comprendre qu'on fait de la merde quand on va rechercher à l'intérieur d'une boucle le nom de chaque produit d'une commande.
Et le plus grave dans tous cas, c'est qu'un ORM pousse le développeur à totalement ignorer la partie base de données. Par conséquent, outre la modélisation généralement hasardeuse, on se retrouve avec une mauvaise utilisateur de l'ORM lui-même, tout simplement parce que "c'est plus simple de faire des requêtes dans une boucle qui est dans une boucle dans une autre boucle". J'ai même vu du code où le développeur chargeait des millions de lignes pour calculer le total lui-même… l'explication "ben je savais plus comment on faisait la somme, alors là ça allait plus vite de faire comme ça que de chercher dans la doc".
Partager