Comment choisir entre garder une base unique ou un entrepôt pour les rapports?

[Ryan19]

Je suis en train de préparer la nouvelle version de notre petite appli interne au boulot, et je me retrouve bloqué sur un choix qui a l’air bête. Actuellement, on a tout dans une seule base PostgreSQL, mais avec les nouvelles fonctionnalités, les requêtes commencent à ramer un peu sur les rapports mensuels. Un collègue me dit qu’on devrait tout garder tel quel et juste optimiser les index, un autre me souffle qu’on devrait séparer les données historiques dans un entrepôt de données dédié. J’ai l’impression que les deux approches ont un sens, mais je n’arrive pas à trancher. Vous avez déjà eu ce genre de dilemme entre garder une architecture simple et scinder ?

[Joseph.A]

Bonne question et franchement j hésiterais entre deux philosophies. Si vous gardez tout dans une seule base PostgreSQL vous pouvez pousser l optimisation des index et faire des partitions sur les tables historiques. Le gain de performance peut suffire pour les rapports mensuels si les requêtes restent lisibles et que vous évitez les scans lourds.

[Nora23]

Pour moi la seconde voie a du sens surtout si les rapports freinent et que les historiques s'empilent. Un entrepôt de données peut charger les historiques en batch et offrir un schéma optimisé pour l OLAP. Cela peut améliorer la performance des requêtes mensuelles sans bouleverser la base opérationnelle.

[Brandon96]

Et si le vrai enjeu est le coût de maintenance et le temps de réponse des rapports sur un mois plutôt que le mot separer ou non ce qui touche directement la performance ?

[TimothyJ]

Je suis partagé j aime la simplicité et j aime aussi l idee de pouvoir faire parler les données historiques sans toucher au système opérationnel. La performance des rapports compte et je crains que le coût de maintenance soit caché sous de grandes promesses.

[JerryFH]

Et si on adopte une approche hybride avec des vues matérialisées et des répliques en lecture pour les rapports tout en conservant le système opérationnel cela permet d isoler les requêtes lourdes sans bouleverser l'application.

[David.T]

Franchement l idee d un entrepôt pour un petit outil interne me semble surdimensionnée a moins que vous ayez des charges massives. Si on peut reduire le temps de calcul par l indexation et un partitionnement judicieux on peut rester dans une architecture simple et efficace. La performance peut venir d un bon compromis.