On parle ici de mécanismes basiques de la plateforme Simplicité qui, visiblement, ne sont pas bien maîtrisés…
Un attribut “ID” (ou “foreign key”) peut, comme tout attribut d’un objet, être obligatoire ou facultatif.
Ce type d’attribut induit une jointure logique entre l’objet et l’objet qu’il référence. Comme rappelé précédement cette jointure logique se traduit au niveau physique par:
- un
inner joinsi l’attribut ID est obligatoire - un
outer joinsi l’attribut est facultatif
Votre différence de comptage logique/physique s’explique donc par un (ou plusieurs) attribut ID obligatoire mais pour lequel il existe des records sur lesquels la colonne est nulle (peut être parce que cet attribut était facultatif à une époque ou pour une raison plus subtile dans vos paramétrages/contraintes/code/…)
Repassez vos attributs ID en facultatifs pour retrouver ces records filtrés par le inner join, corrigez les, et repassez les attributs en obligatoires.
Plus généralement relisez votre paramétrage/code pour voir si le caractère obligatoire/facultatif de ces ID est bien légitime au regard de vos besoins métier, et surtout si vous avez mis en place des règles dynamiques sur le caractère obligatoire ou facultatif d’attributs IDs assurez vous de l’avoir fait d’une manière qui le rende facultatif sur les listes.
De manière générale je recommande de ne pas jouer avec le caractère obligatoire/facultatif des ID dans des contraintes ou le code, à fortiori si vous faites des choses au niveau physique qui ne sont pas cohérentes avec les règles mises en place au niveau logique.
Une autre manière de le dire (et donc d’éviter des différences logiques/physiques) c’est de travailler exclusivement au niveau logique (ex: faire un myObject.count() plutôt qu’un select count(*) en base). Dans Simplicité le recours au SQL en base ne soit se faire que quand justement, pour de bonnes raisons, on souhaite zapper ce qu’il se passe au niveau logique.