Comment éviter les jointures lourdes lorsque l'on normalise son schéma?

[AddisonJC]

Je viens de passer une semaine à essayer de migrer une vieille appli qui utilisait des fichiers plats vers une vraie base de données relationnelle, et je suis un peu perdu sur un point. J’ai tout modélisé avec des tables séparées pour les clients, les commandes et les articles, mais dès que je dois reconstituer une vue complète pour un rapport, je me retrouve avec des jointures qui alourdissent tout. Je me demande si j’ai mal conçu mon schéma dès le départ, ou si c’est juste normal de devoir jongler avec autant de requêtes pour un résultat simple. Le concept de normalisation est censé clarifier les choses, mais là, j’ai l’impression d’avoir créé une usine à gaz.

[AaronR]

la normalisation est utile pour éviter les redondances mais elle ne garantit pas des rapports faciles. quand on a des clients commandes et articles il faut des jointures pour reconstituer un etat complet et cela peut devenir lourd. on peut compenser en identifiant les cas de reporting lourds et en ajoutant des vues matérialisées ou une couche de reporting dénormalisée pour les requêtes courantes sans toucher au modèle opérationnel

[Victoria.G]

oui le ressenti d une usine à gaz est réel et la normalisation est parfois vue comme une contrainte déplacée. j ai tendance à penser que le problème vient moins de la théorie que de l usage pratique du schéma dans les rapports. parfois on croit que tout doit être normalisé alors que des entités de dimension et des faits peuvent aider au reporting sans tout dénormaliser

[StevenM]

peut être que le cœur du souci c est que vous avez démarré trop strictement avec une normalisation parfaite et que les besoins de reporting n ont pas été anticipés. le schéma devient alors une usine à requêtes et l efficacité s effrite. dans ce cas une approche pragmatique peut consister à isoler les besoins de rapports dans une couche dédiée tout en conservant l intégrité des données

[Riley.M]

pour reformuler le problème il est possible que vous cherchiez un moyen de passer d un modèle opérationnel normalisé à une vue unique pour les rapports sans écrire des centaines de jointures. si on prend cela comme point de départ on peut tester des marts ou des structures dédiées pour le reporting tout en restant fidèle à la normalisation pour l opérationnel

[Justin_D]

les attentes des lecteurs et le style d écriture influent aussi sur ce choix. certains veulent des chiffres précis et des calculs rapides d autres apprécient une présentation simple mais plus lente à charger. le mot clé normalisation est utile mais il ne suffit pas il faut aussi penser à la lisibilité et au rythme des requêtes et des explorations

[EricT]

en fin de parcours l idée plus large c est que le choix entre normalisation et dénormalisation reflète des compromis entre évolutivité et vitesse d analyse dans une vraie équipe data et que le rapport final peut n avoir besoin que d une vue adaptée sans être un miroir exact du modèle opérationnel