Parser une requête et trouver tous les champs utilisés
Bonjour.
Je voudrais savoir si quelqu'un a déjà trouvé un moyen de parser une requête, allant d'un simple select d'une table à une imbrication de sous-requêtes avec des opérateurs ensemblistes, pour en retirer les champs (et tables) utilisés dedans.
J'ai trouvé ça et ça mais ça ne répond pas tout à fait à ma problématique. J'ai regardé DBMS_SQL et DBMS_UTILITY aussi mais je n'ai pas trouvé mon bonheur.
En fait j'aurai besoin d'une commande / API distribuée par Oracle et qui analyse sémantiquement la requête et renvoie la liste des colonnes utilisées dedans, que ce soit en restitution, en filtre ou en jointure. Oracle a forcément ce genre fonction en interne, sinon comment ferait le parser pour déterminer qu'une table ou un champ n'existe, mais est-ce qu'ils l'ont rendu accessible ? Je ne sais pas.
Une technique à laquelle j'ai pensé consiste à prendre la requête (valide) et à volontairement introduire des caractères improbables à la fin de chaque "mot" pour provoquer une erreur de parsing et donc savoir que ce "mot" était un nom de table (ORA-00942) ou de champ (ORA-00904) mais déjà c'est une technique très "force brute" et surtout un ORA-00904 ne me permet pas de faire la différence entre un nom de fonction et un nom de champ. J'ai pensé aussi à utiliser DBMS_UTILITY.NAME_RESOLVE mais cette méthode ne fonctionne que pour les tables.
Il y a aussi des parser SQL en java, notamment un distribué par Oracle mais j'ai moyennement confiance sur la qualité du parsing, surtout que chez mon client, quand on créé une vue c'est justement pour éviter une requête très compliquée.
Bref je sèche un peu sur le sujet...
Fonctionnellement, le but est de pouvoir faire automatiquement des analyses d'impact pour déterminer quelle requête ou vue peut être impactée par une modification DML ou DDL. Je peux déjà le faire d'une manière très macro (au niveau des tables) avec ALL_DEPENDENCIES mais je voudrais vraiment pouvoir descendre au niveau du champ.
Merci de vos idées / conseils / astuces
PS : Oracle 10g mais si ça marche en 9i c'est bien aussi (comme ça je pourrais ré-utiliser la solution ailleurs).
