remarques article : Darwinisme et informatique : les ORM...
bonjour,
voici plusieurs remarques sur l'article : Darwinisme et informatique : les ORM et les frameworks survivront-ils au concept de développement en base de données épaisse ?
Citation article :
Il s'ensuit une analyse des retours d'expériences menées par l'auteur en comparant les développements conçus par l'approche traditionnelle et celle du concept de développement
épais côté bases de données.
Et le constat fait froid dans le dos...
o réduction par un facteur 3 à 4 des lignes de code client, donc réduction potentielle par
ce même facteur des bugs non encore découverts;
o division par un facteur 10 à 100 des temps de réponse du système;
o réduction par un facteur 2 à 3 du temps global de développement.
L'article cité (http://www.dulcian.com/Articles/Thic...ited_final.htm ) fait des comparaisons biaisées. Notamment l'auteur compare des développement dits traditionnels aux développements base de données épaisse MAIS dans les 2 premiers cas cités sont biaisés.
Exemple 1 : the most significant performance problems [en développement traditionnel] were due to poorly coded SQL
Exemple 2 : Performance was poor, mainly because of excessive round trips and unnecessary full tree refreshes. [en développement traditionnel]
L'auteur reconnaît lui même le biais dans ses analyses !!!: It is somewhat unfair to apply the thick database approach to existing, poorly performing systems since this may only highlight its possible effects on projects that would particularly benefit from using the approach. Also, it is always easier to build something better the second time.
Il donne alors un dernier exemple censé ne pas être biaisé mais il donne peu d'informations.
Citation article :
Malgré tous les caches qu’on leur met, les performances sont divisées par un facteur important par rapport à une série d’insertions faites directement depuis le code client. La phrase s'appuie sur 2 référence. La première référence compare HIBERNATE versus du code JDBC fait à la main et conclue que le JDBC est bien meilleur.
Dans le livre «*java persistance with hibernate*» les auteurs (les créateurs d'hibernate) disent : The really interesting question is what happens when we consider time and budget constraints?
Given a persistence task, many optimizations are possible. Some (such as query hints) are much easier to achieve with hand-coded SQL/JDBC. Most optimizations, however, are much easier to achieve with automated ORM. In a project with time constraints, hand-coded persistence usually allows you to make some optimizations. Hibernate allows many more optimizations to be used all the time. Furthermore, automated persistence improves developer productivity so much that you can spend more time hand-optimizing the few remaining bottlenecks.
Ailleurs ils disent : the main purpose of up to 30 percent of the Java application code written is to handle the tedious SQL/JDBC and manual bridging of the object/relational paradigm mismatch
Sur un projet réel développé récemment dans mon service, hibernate a été utilisé avec HQL pour plus de 95% des requêtes. Pour les 5% restantes il a fallu passer par SQL pour des questions d'optimisation. Au final, le code est suffisamment optimisé pour nos besoins et le temps de développement aurait été plus long si on avait tout fait en JDBC/SQL.
Citation article :
Quant à l’argument qui consiste à dire que la maintenabilité du code d’un langage client est bien plus simple que du SQL, j’ose dire qu’elle est d’une évidente stupidité : avoir 3 à 4 fois moins de lignes de code en matière relationnelle qu’avec du code itératif induit mathématiquement le fait qu’il y aura proportionnellement moins d’intervention à y faire.
La comparaison n'a pas vraiment de sens. Si je me réfère à JAVA une bonne partie du code peut être généré par l'IDE (ex: getters et setters) et ne demandent aucune maintenance. Il faudrait enlever ces lignes de codes pour comparer proprement.
De plus la maintenabilité ne dépend pas uniquement du nombre de lignes de code. Par exemple, la modularité du code joue également tout comme la qualité de la documentation (la JAVADOC c'est très bien et c'est dans le code donc syncronisé avec. Existe t'il une aussi bonne façon de faire de la doc en PL SQL?)
cordialement
loïc midy
