Architecture récupération statistiques

Bonjour
(j'ai déjà lancé cette discussion dans la partie architecture mais personne ne m'a répondu :cry:, donc je vais la relancer dans cette branche du forum en espérant trouver de l'aide. Merci d'avance)


Dans le carde d’une architecture n-tier, Vue-Service-Dao l’équipe technique n’arrive pas à trancher sur la mise en place d’un calcul de statistiques
Il s’agit du calcul de statistique déduit des sommations d’un ensemble de groupement
- Certains disent que ce besoin peut être fait dans une seule requete SQL (avec des sum et des groupes by sur les critères pour lequel les statistiques doivent être récupérées et cela dans le DAO avec du jdbcTemplate)
- Alors que d’autres répliquent que le groupement est une problématique métier, donc ils veulent à partir d’une seule requête HQL avec le fetching nécessaire’ renvoyer tout le graphe d’objets puis après dans le service Java faire le groupement demandé (récupérer à partir d’une jointure les objets puis faire au niveau java les groupement et les sommations)

Quels sont les avantages et les inconvénients de chacune de ces méthodes et les cas où il faut privilégier l’une à l’autre.

- Tout faire en SQL : performant, simple à faire, mais nécessite la maintenance du code SQL en plus du code java.

- Tout faire en HQL, mais en ramenant directement les indicateurs : performant, mais souvent chiant à faire. A l'avantage d'avoir toute la logique métier au même endroit.

- Ramener via hibernate tous les objets pour faire les calculs : très rapidement atroce question performance ! Idem, toute la logique métier au même endroit.

Citation:

---

Envoyé par Rei Ichido

- Tout faire en HQL, mais en ramenant directement les indicateurs : performant, mais souvent chiant à faire. A l'avantage d'avoir toute la logique métier au même endroit.

---

Je serai toi, je ferai tout en HQL, tu peux très bien dans une HQL aller chercher toute ta grappe d'objets en y mettant les clauses where et group by qu'il faut. L'avantage de cette requete c'est que les traitements sont plus rapides et consomment moins quand ils sont executés en base, et en 2e si ta requete est externalisée dans ton projet, demain si tu veux l'optimiser t'as pas besoin de relivrer entierement ton appli.

Le principal problème du HQL, c'est que je trouve ça rapidement illisible dès qu'il y a beaucoup d'objets à requêter. Peut-être que j'ai été échaudé par des applis avec un fonctionnel (très) complexe ...

Citation:

---

Envoyé par Rei Ichido

Le principal problème du HQL, c'est que je trouve ça rapidement illisible dès qu'il y a beaucoup d'objets à requêter. Peut-être que j'ai été échaudé par des applis avec un fonctionnel (très) complexe ...

---

C'est vrai, surtout quand ils s'agit des statistiques complexes nécessitant quelques unions.

- Faire du SQL dure c'est tendre vers le max niveau perf, et niveau de maintenabilité se complique vite à partir des statistiques de complexité moyenne

- Faire Hql c'est à privilégier quand c'est possible, c'est aussi performant. en terme de maintenabilité c'est aussi en fonction de la complicité des statistiques demandées

Mais vous ne voyez que le choix d'une de ces deux techniques se contredit pas avec l'architecture elle même. C'est une archi qui se compose d'une couche java qui est censée en plus d'être exposée comme des services, de faire aussi les traitements métier, vous ne voyez pas que les sommations ou les autres types d'agrégation associés aux groupements, et aux unions ne font-ils pas partie des responsabilités de cette couche, en plus, nous avons un model de domain qui sera complètement absent lors de ce type de traitement. Est ce que cela veut dire que dans le cas d'une application demandant bcp de statistiques le choix d'un outil de mapping serait mauvais? :)

La séparation absolue de ce qui est métier ou pas est purement virtuelle, et n'a pas à être strictement déterminée par un point de vue matériel.

La couche métier peut très bien inclure une partie stockée dans la BDD sous forme de procédures / vues ; il faut juste avoir conscience du besoin accru en terme de maintenance. Cela dit, concrètement quand on veut faire du HQL complexe, c'est limite pire : tout est au même endroit, certes, mais il faut quelqu'un de compétent en java et en sql pour faire du HQL propre, là où un découpage java / sql peut permettre d'avoir 2 personnes (oui, je sais, en général les compétences sont doubles de toute façon).

Si vous tenez absolument à faire les traitements "côté java", le choix HQL (ou SQL embarqué, d'ailleurs, c'est pas comme si on ne pouvait pas stocker le SQL côté hibernate) permet toujours d'avoir une séparation logicielle.

Tenir absolument à rapatrier les données de la BDD en POJO juste pour le plaisir de pouvoir affirmer que le "traitement métier" est intégralement fait dans "la couche métier", je trouve ça absurde, et ça ne tient pas la route en terme de performance dès qu'il y a un tant soit peu de volumétrie.

Un projet de récupération de statistique est par définition très coûteux en terme de perf et en terme de complexité des requête car un base métier n'est pas organiser pour ça. Et y a fort à parier que la base de données va prendre une grosse claque et que les appli métier vont en ressentir l'effet quand on va consulter les statistiques et pire il n'est pas sûr que la base métier garde un méga historique, un jour un DBA va dire qu'il faut faire le ménage et les stats vont être fausse en suite.
Donc on théorie on refait une nouvelle base de type OLAP et on l'attaque avec un API dédié et la ça marche. Par contre il faut alimenter la base OLAP avec un ETL (Talend Open Studio par exemple). C'est du boulot aussi.