Le besoin est d’avoir un tableau synthétiques de tous les champs utilisés dans l’application qui soit facilement exploitable (feuille de calcul).
Ca semble extrêmement proche de la doc markdown que je vous ai indiquée et qui sort deja une vue logique complète des objets et de leurs attributs avec les commentaires saisis dans le paramétrage, ex:
Il manque juste les noms physiques (table, colonne ou autre), on peut l’ajouter facilement même si on ne voit pas forcément l’usage que ça peut avoir dans la mesure où il faut éviter d’aller taper dans la base de données mais toujours privilégier les couches logiques (API, I/O, etc.)
En tout cas ne vous embêtez surtout pas à réécrire du SQL compliqué pour refaire ce que le moteur Simplicité fait déjà.
Comme je l’ai déjà dit avec Simplicité il faut avoir le voyant qui s’allume => “si je suis en train d’écrire du SQL je fais sans doute fausse route”.
Il faut toujours s’astreindre à manipuler les objets logiques. Les cas où on a recours au SQL doivent être des cas très tordus où on sait exactement pourquoi utiliser les objets logiques n’est pas adapté.
Bref dans votre cas c’est clairement pas une requete SQL qu’il faut écrire c’est une publication qui parcoure ObjectInternal, ObjectField, Field, etc.
NB: Il y a un exemple de publication sur template qui parcours des objets/attributs/etc. dont vous pourriez vous inspirer (publication XMI):