Historiquement les bases sont plus performantes avec un “inner join” qu’avec un “outer join”, du coup une FK obligatoire a toujours été interprétée en “inner join” SQL.
Mais c’est vrai que ça a toujours posé des problèmes quand une référence devient obligatoire (suite à un évolution ou dynamiquement…) pour la reprise des données, une erreur d’import…
A l’inverse, les attributs obligatoires et non clés fonctionnelles sont facultatifs physiquement pour permettre de les rendre obligatoires dynamiquement dans la couche logique : la base n’est là que pour assurer une persistance/indexation des données.
Il faudrait refaire un série de tests de performance pour comparer les outer/inner join. Si c’est concluant on pourrait faire sauter la contrainte “inner” physique comme pour un attribut. Même avec un “outer join” si la couche logique est bien respectée, aucun null ne devrait exister/remonter, mais si un pb fonctionnel apparaît l’utilisateur serait moins bloqué et pourrait corriger ses données comme pour un champ devenu obligatoire.
Par ailleurs vous pouvez activer les traces SQL temporairement (param système LOG_SQL_USER=yes) pour debugger le “select count” en question.