Discussion :

[loicmidy]

C'est d'un simplicité enfantine.
Si vous avez lu l'article en entier je conseille de ne travailler qu'avec des procédure stockées, ce qui est le plus portable, et d'en faire une pour chaque CRUD (INSERT, SELECT, UPDATE, DELETE).
Il est alors d'une simplicité biblique de les tester unitairement...

A +

1: je croyais que les procédures stockées et plutôt difficiles à porter d'un SGBD à un autre voire d'une version d'un SGBD à une autre.

2 : avec HIBERNATE et JAVA on ne code le CRUD qu'une fois avec un DAO générique :on utilise des éléments qui font la force de JAVA (il a des mécanismes analogues dans d'autres langages objets) : héritage et générics => moins de code à écrire qu'en PL SQL sur ce cas précis.

3 : un test unitaire doit permettre de tester le bon fonctionnement d'un bout de code en isolation des autres. En JAVA c'est possible avec les mock (avec les librairies de mock on a peu de chose à écrire à la main). en PL SQL celà ne me semble pas possible ou difficilement.
ex : une procédure A fait un traitement et appelle des traitements faits dans des procédures B et C. Comment tester A sans utiliser B ni C?

4 : l'ensemble des tests unitaires doivent tourner rapidement.
en JAVA 80/90% des tests unitaires seront sur la couche métier et la BDD ne sera pas sollicitée (on mocke les DAO) et les tests unitaires restant porteront sur les DAO : pour ces cas, on remplit une BDD de test avec un jeu de données de test puis on joue le test unitaire puis on remet la BDD de test dans son état initial. On procède ainsi afin de respecter une autre règle sur les tests unitaires : leur indépendance entre eux.
Au final l'ensemble des tests unitaires passeront très vite.
en PL SQL il faudra taper dans la BDD de test pour tous les tests (et après chaque test la remettre dans l'état initial) => l'ensemble des tests unitaires passeront beaucoup plus lentement.


cordialement
loïc midy

[loicmidy]

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

[dingoth]

C'est drôle combien certains pensent toujours que le terme "portabilité" signifie une seule techno, mais 10 SGBDR, alors que l'inverse non.


Mettons une seule base de données, mais avec une interface de gestion en HTML sur serveur d'app Java, une interface d'utilisation en C++ et une troisième en PHP pour les visiteurs occasionnels.

Vous aimeriez avoir à recoder le tout à chaque fois dans chaque langage ? Où placer le métier dans ce cas ? Il faut le coder 3 fois ou une seule fois dans la base de données ? Où est le véritable gain de temps ?

Ce genre d'architecture n'est pas si rare (et ce n'est pas parce que vous ne l'avez pas rencontré qu'elle n'existe pas).

[davcha]

Ou alors, tu codes un service qui tape dans la base de donnée et qui fournit ce qu'il faut aux différents satellites de ton truc.

[B.AF]

C'est drôle combien certains pensent toujours que le terme "portabilité" signifie une seule techno, mais 10 SGBDR, alors que l'inverse non.


Mettons une seule base de données, mais avec une interface de gestion en HTML sur serveur d'app Java, une interface d'utilisation en C++ et une troisième en PHP pour les visiteurs occasionnels.

Vous aimeriez avoir à recoder le tout à chaque fois dans chaque langage ? Où placer le métier dans ce cas ? Il faut le coder 3 fois ou une seule fois dans la base de données ? Où est le véritable gain de temps ?

Ce genre d'architecture n'est pas si rare (et ce n'est pas parce que vous ne l'avez pas rencontré qu'elle n'existe pas).

Oui, c'est même plutôt courant. Après cela dépend aussi de ce que tu fais.
Imaginons que tu vendes un ERP quelconque, une apppli de gestion :
- Tu vas chez X, tu es 100%, sauf l'IT qui homologue "DB2 sous linux"
- Tu vas chez Y, tu es 100%, sauf l'IT qui homologue "SQL 2005 sous 2008 R2"

Moi je crois que c'est surtout l'aspect "systèmatique" du recours aux sgbd qui a créé ce besoin d'indépendance, pour pouvoir créer des offres qui s'intégrent aussi dans les systèmes clients. La situation que tu décris est le vision interne de la donnée, la situation de l'indépendance est la vision externe.

En ce moment je regarde des moteurs nosql par ex, et pour des processus complexe ou des archi multi-tenancy, c'est très intéressant, en tous cas beuacoup plus performant et adapté que des modéles relationnels.

Il y a toujours un cout d'exploitation. Sa rationalisation ce n'est pas de faire du prosélitisme "tout en SQL Server" comme le fait SQL Pro. Le monde est diversité.

Il s'agit de trouver l'architecture la plus performante au regard d'un contexte et pas que du point de vue de la donnée.
Une architecture ouverte hétérogéne ? Oui ! Si dans son environnement chaque compêtence est présente et assumée, oui ça présente du sens.
Une architecture J2EE dans une boite où tout est VB6 + Access ? Non ! Ce n'est plus une question d'architecture, mais une logique de conduite du changement.

Et dans la culture Française (c'est un constat) nous sommes très résistants au changement. Ce qui a souvent tendance à être un critére fort d'échec.

[epsilon68]

est-il bien d'utiliser un ORM quand N applications accedent à une BD?
ne factorise-t-on pas le code en utilisant des stored procedures?
j'avais aussi compris qu'un ORM n'aimait pas qu'on modifie la DB sans lui dire... (caches pas mis a jour)
aussi si le code est dans les N applications, n'est-il pas interessant de modifier une seul fois le code coté database, sans que les appli soient touchés?

[hegros]

est-il bien d'utiliser un ORM quand N applications accedent à une BD?
ne factorise-t-on pas le code en utilisant des stored procedures?
j'avais aussi compris qu'un ORM n'aimait pas qu'on modifie la DB sans lui dire... (caches pas mis a jour)
aussi si le code est dans les N applications, n'est-il pas interessant de modifier une seul fois le code coté database, sans que les appli soient touchés?

C'est plus une question d'architecture applicative que d'utiliser un ORM ou des procédures stockées. Dans une architecture N-tiers tu vas mettre toute l'utilisation de l'orm ou des procédures stockées dans ta couche application donc c'est tout aussi bien factorisé avec l'un qu'avec l'autre. Et si le code est partagé par N applications tu n'as qu'a modifier ta couche application (donc soit les procédures stockées soit l'utilisation ORM). Dans les 2 cas cela ne change rien.

Pour ma part l'utilisation d'un ORM simplifie (quelque fois et uniquement pour ce que j'en ai vu avec linq parce que les autres...) et généralise l'écriture de requêtes. Et en simplifiant alors la maintenance est plus facile et comme la maintenance c'est 87% du temps que l'on passe sur un logiciel.

[B.AF]

est-il bien d'utiliser un ORM quand N applications accedent à une BD?
ne factorise-t-on pas le code en utilisant des stored procedures?
j'avais aussi compris qu'un ORM n'aimait pas qu'on modifie la DB sans lui dire... (caches pas mis a jour)
aussi si le code est dans les N applications, n'est-il pas interessant de modifier une seul fois le code coté database, sans que les appli soient touchés?

Là c'est une question différente : ça léve la question du SI vs une application.
Pour éviter de faire cela, on a préconisé les architectures de service, de telles façon que toute application puisses accéder à des données sans justement révolutionner l'informatique en distribuant des transactions sur n applications.

Quand la DB est un élément METIER central, il faut effectivement faire preuve de bon sens et raisonner en termes de services et utiliser des sp ou des éléments qui ne vont pas transformer un système d'information en un patchwork technologique.
En outre, SP et ORM ne sont pas incompatibles ni exclusifs.

[epsilon68]

Comment font les ORM quand la database est modifié en dehors de leur controle? J'ai cru comprendre que ca n'aimait pas du tout ca, beaucoup de probleme avec les caches etc.

[davcha]

Ca dépend. Tu parles d'une modification des données ou de la structure ?

Si la structure est modifiée c'est clair que c'est le bordel. Mais ça le serait également autrement (sauf à tout mettre derrière une facade view/procédures stockées, mais si tu modifies ta facade, tu as le même problème).

Si tes données sont modifiées, ton ORM et ta base sont désynchronisés, et ça peut facilement devenir pénible à gérer.

[B.AF]

Comment font les ORM quand la database est modifié en dehors de leur controle? J'ai cru comprendre que ca n'aimait pas du tout ca, beaucoup de probleme avec les caches etc.

"Ils" ne font rien. D'une façon plus générale, c'est à déconseiller fortement.

[_skip]

En même temps on ne crée que rarement des caches sur des données susceptibles d'être modifiées depuis l'extérieur si l'on doit impérativement refléter les changements immédiatement.

C'est pas une limitation d'un ORM, mais bel et bien du principe même d'un cache.

[epsilon68]

peut-on agir sur le cache? (je ne crois pas)
peut-on interdire d'utiliser le cache sur une table precise? (je ne crois pas non plus)

ensuite sur la modification de structure, j'avais compris que meme un champs rajouté faisait que l'ORM ne marchait plus. Vous confirmez?

[davcha]

ensuite sur la modification de structure, j'avais compris que meme un champs rajouté faisait que l'ORM ne marchait plus. Vous confirmez?

Quand même pas non.

Sauf si c'est un champ not null sans valeur par défaut.

[B.AF]

peut-on agir sur le cache? (je ne crois pas)
peut-on interdire d'utiliser le cache sur une table precise? (je ne crois pas non plus)

ensuite sur la modification de structure, j'avais compris que meme un champs rajouté faisait que l'ORM ne marchait plus. Vous confirmez?

De toutes les façons, le problème principal vient de la gestion des états et de la concurrence. Ce qui va se traduire par un dysfonctionnement majeur de l'ORM n'est que le reflet d'une défaillance bien plus grave qui est l'intégrité référentielle de la base.

Les ORM sont tous différents donc il est difficile de généraliser un comportement, donc on ne peut rien confirmer ou infirmer. A l'identique sur les questions de cache.

Ta question au final reléve plus de dire : faut-il préconiser une architecture client serveur hétérogène (A savoir n architectures clientes pour une seule et même db avec des accès concurrents) ? La réponse est simple et définitive : non.
Si il y a un moment besoin de n clients accédant à la même donnée, là il devient nécessaire de se poser la question du service.

[davcha]

Précises, B.AF : n instances différentes du même client ou n clients différents.

[fr1man]

peut-on agir sur le cache? (je ne crois pas)
peut-on interdire d'utiliser le cache sur une table precise? (je ne crois pas non plus)

Concernant Hibernate, le cache est paramétrable.
Tu peux l'activer ou pas pour telle ou telle entité, donc table.

[B.AF]

Concernant Hibernate, le cache est paramétrable.
Tu peux l'activer ou pas pour telle ou telle entité, donc table.

A moitié faux. Tu ne peux pas manipuler celui qui sera le plus gênant dans ce cas et qui sera le cache de niveau 1, qui est en fait le registre des entités manipulées par la session actuelle.

Il existe bien un cache de second niveau, mais qui lui ne sera qu'un problème supplémentaire.

[fr1man]

Oui je parlais du cache de niveau 2, j'aurais du préciser.

Quant à dire que son utilisation ne sera qu'un problème supplémentaire, faut pas pousser non plus.

[B.AF]

Oui je parlais du cache de niveau 2, j'aurais du préciser.

Quant à dire que son utilisation ne sera qu'un problème supplémentaire, faut pas pousser non plus.

Je ne sais pas quels caches tu utilises, mais l'invalidation ou la synchronisation sont des notions importantes.

Si tu utilises un cache x (prevalence, ou memcache par ex). Tu te dis à juste titre : j'ai une entité dont j'ai fréquemment besoin. Tu décides donc d'initialiser un pool d'objet d'utiliser le cache pour limiter les hits db. Ce qui semble être une bonne idée.
Pendant ce temps, une application omega vient modifier en raw sql les données utilisée pour générer les entités en cache.
Ces modifications ne passant par ta couche d'accès aux données, tu recevras les données que tu as initialement cachées, qui seront incohérentes avec les données physiquement en base.
A moins de construire une usine à gaz de listener avec certains moteurs de caches, tu cours droit à la catastrophe car tu induis alors une faille dans ta conception logicielle.