L’autre jour je suis tombé sur un problème de comptage dans BO.
L’univers contenait des indicateurs agrégés et non agrégés sur la même table.
Certains indicateurs étaient agrégés pour question de performance, et d’autres ne l’étaient pas pour pouvoir les mettre en condition sans que BO ne les agrège.
Problème, si on prend les 2 types d’indicateurs dans la même requête, un groupement par l’indicateur non agrégé se fait 
Un exemple sera plus parlant :
On a une table VENTES
client montant
TOTO 120
TOTO 100
TITI 80
TITI 80
et 2 indicateurs :
nombre clients=count(distinct client)
la requête suivante est bonne :
TOTO 220
TITI 160
somme 380
Ainsi que :
2
Mais si on prend les 2 indicateurs les résultats sont faux :
2 300
car on a en SQL
select
count(distinct VENTES.client),
VENTES.montant
from VENTES
group by VENTES.montant
Comme quoi il faut être vigilant sur les normes mises en oeuvre sur un univers, et garder les mêmes règles pour tout indicateur. Si on utilise les fonctions d’agrégation sur un indicateur ( et cela inclut le count() ), il faut faire de même sur les autres.
Oui, on n’a pas ce problème si on a la somme dans le SQL de l’objet (c’est ce que je sous-entends à la fin). Mais des fois on ne met pas de somme dans les indicateurs, notamment pour éviter les problèmes d’agrégation dans les conditions.
Par exemple avec une somme dans le SQL si tu veux avoir les clients ayant eu une vente supérieure à 150€ tu mettrais juste en condition « Montant>150″ et tu récupérerais TOTO et TITI, car la somme des montants est supérieur à 150€. Soit un résultat faux. Il faudrait rajouter des objets dans la requête, ce qui n’est pas évident pour un utilisateur lambda en conviendras-tu.
Dans l’article j’avais pris le cas d’un univers où aucun indicateur n’était sommé (pour pouvoir les mettre en condition facilement) et où on trouvait des indicateurs « Nombre de » qui utilisaient la fonction count().
Est ce qu’il ne suffit pas de doter Montant de la fonction Somme dans le SQL de l’objet ?