Le rapport annonce 18 000 euros de ventes, alors que le total des commandes atteint 9 000 euros. Aucun client n’a acheté davantage : une jointure SQL a peut-être répété des montants. Ce défaut est particulièrement trompeur, parce que la requête peut s’exécuter sans erreur et produire un tableau très propre.

Une commande et ses lignes n’ont pas la même granularité

Prenons un exemple fictif : une commande de 100 euros contient trois lignes de produits. Si l’on joint la table des commandes à celle des lignes, le montant de la commande peut apparaître sur chacune des trois lignes. Additionner ensuite cette colonne donne 300 euros pour une vente de 100 euros.

La jointure a correctement associé les données. L’agrégation, elle, répond à une question mal définie. Avant de calculer, nommez donc ce que représente une ligne de chaque table : une commande, un article commandé, un paiement ou un événement de livraison.

Cette granularité des données est une propriété métier, pas une subtilité réservée aux développeurs. Un responsable commercial doit pouvoir comprendre pourquoi un identifiant de commande apparaît plusieurs fois dans le résultat.

Vérifier le nombre de correspondances

Choisissez une commande dont vous connaissez le contenu. Affichez son identifiant, son montant et les identifiants associés après la jointure. Vous verrez immédiatement si elle est répétée. Faites la même vérification avec une commande sans correspondance et une commande possédant plusieurs correspondances.

Trois petits cas expliquent souvent mieux le défaut qu’un total mensuel.

Une jointure interne conserve les correspondances trouvées et peut faire disparaître des lignes sans partenaire. Une jointure externe gauche permet de conserver les lignes de la table de gauche, avec des valeurs manquantes lorsque rien ne correspond. Mais elle peut toujours produire plusieurs lignes quand plusieurs correspondances existent. Le mot « gauche » ne signifie pas « une ligne par commande ».

Les filtres appliqués après la jointure peuvent également changer le résultat. Une condition sur une colonne de la table associée peut écarter les lignes sans correspondance. Il faut donc examiner la requête entière, et pas seulement le type de jointure annoncé.

Calculer chaque mesure à son niveau

Le développeur peut agréger les lignes de produits par commande avant de les rapprocher d’un total de commandes. Il peut aussi produire deux mesures distinctes avec des règles explicites. La bonne solution dépend du rapport souhaité, mais elle doit éviter d’additionner une même vente autant de fois qu’elle contient d’éléments.

Ajouter DISTINCT au hasard ne constitue pas une correction fiable. Deux commandes différentes peuvent avoir le même montant ; supprimer des valeurs identiques peut alors effacer des ventes légitimes. La déduplication doit reposer sur des identifiants et un niveau de calcul définis.

Les différences entre moyenne et médiane dans un tableau de bord posent une question voisine : un indicateur ne devient utile que lorsque sa construction correspond à ce qu’on cherche à observer. Ici, le premier contrôle porte sur la population de lignes, avant même le choix du calcul statistique.

Le montant doit avoir son propre repère

Une table peut contenir le montant commandé, une autre le montant payé, une troisième une ligne remboursée. Les joindre ne permet pas d’additionner librement leurs colonnes. Définissez la mesure voulue : vente commandée, encaissement ou montant après remboursement. Les statuts et les dates associés doivent suivre cette définition.

Pour une recette, utilisez une commande partiellement remboursée et une commande réglée en plusieurs fois. Ces exemples révèlent les multiplicateurs créés par les relations entre paiements, lignes et remboursements. Une requête correcte sur les commandes simples peut échouer sur ces relations multiples.

Demandez également comment les montants manquants sont traités. Un zéro, une valeur absente et un montant inconnu ne portent pas nécessairement le même sens. Remplacer toutes les absences par zéro peut cacher un rapprochement incomplet. Le rapport doit distinguer les données réellement nulles des objets qui n’ont pas été trouvés, puis fournir un moyen de revoir ces exceptions.

Demander une preuve de réconciliation

Un rapport livré par un prestataire devrait pouvoir être rapproché d’un total de référence. Pour le même périmètre de dates et de statuts, comparez le nombre de commandes distinctes et leur montant, puis expliquez les écarts éventuels.

Conservez quelques cas de démonstration dans les tests de la requête : une commande sans ligne, une avec une ligne, une avec plusieurs. Lorsqu’un nouveau champ ou une nouvelle table est ajouté, ces exemples permettent de repérer un multiplicateur silencieux. Un tableau de bord fiable commence parfois par une simple question : combien de fois cette vente est-elle entrée dans le calcul ?