Il n’y a
pas une stratégie meilleure qu’une autre, il y a des stratégies meilleures en
fonction des situations.
Dans un cas
GCP compliance, on peut se permettre de sacrifier quelque peu les performances
en faveur de l’intégrité des données. J’opterai donc plus pour une stratégie :
JOINED.
Hibernate n’est
pas ce qu’il y a d’idéal pour du reporting ou encore de l’ETL, là il est
toujours possible d’utiliser une solution annexe comme des vues, directement
attaquées par du SQL natif. Evidemment, ça ne permet plus à l’application d’être
DBAgnostique mais cela permet de régler des problèmes de performances.
La dernière
approche serait évidemment la création d’une base de données OLAP dans laquelle
on chargerait les données en vue du reporting.
Référence :
Ceci dit, concernant les vues, il existe maintenant de nombreux moteurs capable de produire directement du XML...
RépondreSupprimerCe qui d'une certaine façon permet de nouveau de tendre vers l'Agnostisme.
Il est vrai que le reporting n'est pas un élément clé du développement du coeur d'un logiciel, c'est plutôt un développement annexe de "service".
Un peu comme les "services des renseignements" de l'état ne sont pas au coeur de l'état et ne participent pas aux décisions. Ils traitent les données par leurs propres moyen et fournissent les infos adéquates (au format adéquat) pour aider à la prise de décision.
Donc ne pas confondre ni mélanger développement coeur logiciel et développement reporting.
Tout informaticien ayant acquis de l'expérience sais quel problème génère l'inclusion du reporting (un vrai reporting!) au coeur de l'outil de production ;-)
Bonne journée Jyce.