Discussion :

[NiKro75]

Bonjour à tous,

j'utilise un langage particulier d'un gros ERP, qui n'est vraiment pas doué en SQL. A ce titre, j'ai développé une sorte d'éditeur SQL, mais je bloque sur un point, l'analyse de la syntaxe. En effet, j'ai besoin de connaitre les champs sélectionnés, et les tables auquels ils font référence (ou bien leur type).

Google ne m'a pas spécialement aidé, bien qu'un certain nombre de versions plus ou moins payante dans différents langage existent.

A défaut de trouver un code source d'un Parser existant quelconque dans n'importe quel langage (si qqun connais je suis preneur !! ), quel serait la logique, l'algo a respecter pour mettre ça en oeuvre ?

J'ai cru comprendre qu'il fallait initier un arbre avec des noeuds comprendant les différents mots de la requête, mais je ne vois pas vraiment comment.

Idéalement, ce parser devrait pouvoir interpréter des select de select, ainsi que les decode, nvl, etc.

Merci d'avance de vos idées/retours !

NiKro

[CinePhil]

Ce n'est peut-être pas dans le forum "Langage SQL" que tu auras une réponse adéquate ! C'est plutôt de la programmation !

Pour quand même te mettre sur la piste, tu peux décomposer la chaîne SQL en morceaux :
- Ce qui est compris entre SELECT et FROM est normalement constitué de colonnes et éventuellement d'alias, de fonctions de calcul, de branchements (CASE)...
- Ce qui est compris entre FROM et WHERE ou jusqu'à la fin de la chaîne SQL est constitué de tables avec éventuellement des jointures et leurs conditions ;
- Ce qui est compris entre WHERE et GROUP BY ou ORDER BY ou jusqu'à la fin est contitué de conditions de restriction sur les données ;
- Ce qui est compris entre GROUP BY et HAVING ou ORDER BY ou jusqu'à la fin est constitué de colonnes qui doivent normalement figurer parmi la liste des colonnes du SELECT ;
- Ce qui est compris entre HAVING et ORDER BY ou jusqu'à la fin est constitué de conditions de restriction sur les regroupements de données ;
- Ce qui est compris entre ORDER BY et la fin est constitué de colonnes et éventuellement de clauses d'ordre (ASC ou DESC)

Mais bon... bonjour le boulot !

Bon courage !

[NiKro75]

Merci de ta réponse !

En effet, j'ai hésité à poster dans une autre section, comme Algorithme, mais je suppose qu'il vaut mieux éviter de poster n fois le même message dans différentes section

Pour le découpage de la requête, en effet, avec des RegEx, j'arrive à peu près à récupérer ce qu'il y a entre SELECT et FROM, mais dès que j'envisage des cas plus complexe, je bloque. Ex:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
Select A.champ_bis, C.ch
  From ( Select champ As champ_bis
           From matable1, matable2
          Where clé1 = clé2) A
  Join matable C
    on ...

Je peux certes convenir de limiter les syntaxes complexes, mais l'idéal serait d'en traiter au moins quelques unes

[CinePhil]

Ce qui serait bien déjà, c'est d'avoir une seule syntaxe pour les jointures : la normalisée depuis 1992 avec JOIN !

Après c'est vrai que dans le cas que tu donnes et par rapport à ce que j'ai donné comme piste tout à l'heure :

- Ce qui est compris entre FROM et WHERE ou jusqu'à la fin de la chaîne SQL est constitué de tables avec éventuellement des jointures et leurs conditions ;

il y a deux FROM de suite et un WHERE intermédiaire !

[Monstros Velu]

Les parenthèses servent à séparer les groupes, le parser peut les utiliser.

[jcharleszoxi]

sinon, une petite piste qui peut peut etre te mettre sur la voie...

grosso modo, tu parses ta chaine de charactere avec une sorte de boucle,
des bon ptit charindex pour trouver la position de chaque from
et avec des substring, des len (de charindex de "from" ou "select" etc...), en partant du dernier "from" rencontré jusqu'au premier, tu devrais pouvoir decouper et parser ta chaine comme tu le souhaites.
je sais pas si je suis super clair, mais je ne pense pas que ce soit insurmontable (attention, je parle de sqlserver).

Bon courage a toi

[Yanika_bzh]

La creation d'un parser, necessite l'ecriture d'une grammaire non contextuelle adéquate (cf algo d'Earley par exemple).
La bonne etude de cette grammaire vous permettra de gerer efficacement votre anaylse syntaxique (et lexicale).

Bon courage

[pacmann]

Salut !

Tout à fait d'accord avec Yanika_bzh.

Je tiens à mettre l'accent sur le fait que coder un parser, c'est pas un "détail". (Cinephil, je pense que dire "je te donne un indice, puis tu devrais y arriver est un peu périeux, sans vouloir remettre en cause ta capacité à pondre un parser SQL...)

Il faut définir soigneusement ce que sont les expressions de base, toutes les manières de construire une nouvelle expression à partir d'expressions de départ et "d'opérateurs". Bien entendu, comme le montre l'exemple de la table dérivée, c'est totalement récursif... c'est une algèbre, quoi.

Bon courage...

[NiKro75]

Bonjour,

et merci à tous pour vos réponses.

En effet, le langage que j'utilise me permet d'utiliser les RegEx (Expressions Régulières), et me renvoie la position du 1er caractère du mot recherché, voire toutes les occurences. Je sens bien qu'il est possible de créer une sorte d'algo, à base de IF et de CASE, mais je sens que ça ne pas pas être artistique du tout !

pacmann et Yanika_bzh, c'est bien quelque chose tel que vous décrivez que j'aimerais mettre en place, en espérant que ça ne me prenne pas un temps fou.

Jusqu'à présent, à part trouver une multitude de Parser existant et plus ou moins, voire pas du tout, gratuit, ni OpenSource, je n'ai pas trop avancé.

Je vais creuser la piste Earley, si vous en avez d'autres, je suis prenneur !

PS : et j'avoue que je n'étais pas très assidu à mes cours d'algorithmie...

[Yanika_bzh]

Pour parser un langage complet, c'est assez fastidieux.
J'avais realiser un petit parseur durant mes (lointaines) etudes avec un champs lexical assez limité et c'etait deja pas simple.

Cela se repose sur les grammaires formelles avec des regles a enoncer.
Les sous ensembles se decomposent eux memes selon les fameuses regles afin d'arriver a un element atomique de la regle.

Il faut donc enumerer les elements terminaux (qui ne peuvent plus beneficier d'une transformation par une regle) et les regles de transformation (qui ont pour but de transformer un element non terminal en elements terminaux apres n etapes)

Le sujet des grammaires contextuelles et non contextuelles a été traité ici :

http://www.developpez.net/forums/d25...textuelle-tla/

Mais la on s'eloigne du SQL a proprement parler ...

En esperant que cela puisse vous aider
Bon courage et tenez nous au courant