Parser SQL

[popstatic]

Bonjour,

je ne poste pas souvent de messages sur ce forum, mais j'y passe le plus souvent possible et je dois dire que vous faites tous du très bon boulot, tant de vous même que pour la communauté PB.

Alors pour vous j'ai une petite colle....

Je voudrais programmer un parser SQL, mais z'helas je ne vois même pas par quel bout commencer.

j'ai brouilloné quelques petites choses avec des stringfields, findstring et tout et tout, mais ensuite pour effectuer des recherches dans un fichier texte (ayant une certaine structure) je ne vois vraiment pas comment faire.

Récuperer dans des variables les différents éléments d'une commande SQL ça va encore (et encore....) mais ensuite quelle structure doit posseder mon programme? quel genre de fonctions doivent etre créees pour parser efficacement le fichier contenant les données?

la je patauge, toute aide sera donc la bienvenue!

merci d'avance!

[Progi1984]

Il faudrait une procédure qui cherche d'abord la commande principale (select, create, update),
puis d'autres pour les commandes secondaires (from, where, on, group by, order by,...) en fonction de la première commande
Aprés un Select, on cherchera le from, where, order by, etc..
Aprés un update, on cherchera le on, where, etc...

[popstatic]

et une récursivité pour les requetes imbriquées?

[Progi1984]

exact

[popstatic]

j'ai testé ta lib LDB (du mois je crois bien que c'est la tienne), j'ai fait des bench et même si elle fonctionne parfaitement, je trouve les opérations de recherche vraiment très lentes (1,5 seconde pour un tri sur 300 enregistrements.)

A quoi pense tu que cela est du? penses tu qu'il y a moyen de grandement augmenter cette vitesse?

[popstatic]

j'ai isolé la part de code de la fonction LdbSortNum, car des choses me semblent curieuses:

Code : Tout sélectionner

ProcedureDLL LdbSortNum(Field)
  Nb=LdbCountRecord()
  If Nb>1 ; Si au moins 2 enregistrements
    PointerTemp=LdbGetPointer()
    For n=1 To Nb-1
      For i=n+1 To Nb
        LdbSetPointer(n)
        premier.f=ValF(LdbRead(Field))
        LdbSetPointer(i)
        deuxieme.f=ValF(LdbRead(Field))
        If premier.f>deuxieme.f
          SelectElement(Bdd(),n)
          temp.s=Bdd()
          SelectElement(Bdd(),i)
          temp2.s=Bdd()
          Bdd()=temp
          SelectElement(Bdd(),n)
          Bdd()=temp2
        EndIf
      Next i
    Next n
    LdbSetPointer(PointerTemp)
  EndIf
EndProcedure

pourquoi déclare tu premier.f et deuxieme.f dans une boucle? c'est une perte de temps non? ça bouffe des cycles de redéclarer une meme variable a chaque itération non? je n'ai pas tailbite donc je peut pas tester avec une déclaration précédement effectué.[/b]

[Dr. Dri]

la portée de la variable ne sera pas la boucle mais la procédure, elle ne sera donc pas redéclarée a chaque fois

Code : Tout sélectionner

Procedure test()
  i.l
  For i = 1 To 10
    a.f + 1.1
  Next i
  Debug a
EndProcedure

test()

Dri

[popstatic]

ok c'est bon a savoir, mais alors comment optimiser cette libLDB?

[Progi1984]

PS : ce n'est pas la mienne !

[popstatic]

arrgh désolé, mais la question tiens toujours!

[Anonyme2]

Peut-être que ça irait plus vite en modifiant ceci

Code : Tout sélectionner

  If premier.f>deuxieme.f
     SelectElement(Bdd(),n)
     temp.s=Bdd()
     SelectElement(Bdd(),i)
     temp2.s=Bdd()
     Bdd()=temp
     SelectElement(Bdd(),n)
     Bdd()=temp2
  EndIf     
    

par ceci

Code : Tout sélectionner

  If premier.f>deuxieme.f
    SelectElement(Bdd(),n)
    *PremierElement  = @Bdd()
    SelectElement(Bdd(),i)
    *DeuxiemeElement = @Bdd()
    SwapElements(Bdd(), *PremierElement, *DeuxiemeElement))
  EndIf     

mais je pense que SwapElements() échange tous les champs (je suppose car je ne l'ai pas utilisé) donc si la liste chaînée a un seul champ, c'est OK, sinon ça ne correspond pas.

Il me semble que le tri est un tri à bulle, ce n'est pas Le tri le plus rapide mais je ne suis pas un spécialiste du tri. Il faudrait chercher un algorithme plus rapide.

[popstatic]

il me semble que le tri le plus rapide est le "tri compteur" car il n'utilise pas de comparaison, par contre on est obligé de charger en mémoire l'integralité de ce qu'il y a à trier.

merci pour le code, je vais tacher de le changer pour voir si il y a un gain remarquable.

[Anonyme2]

Autre chose,

n commence à 1 alors que l'indice du premier élément d'une liste chaînée est 0

ce qui veut dire que le 1er élément n'est pas pris en compte

n vaut au début 1 et i 2