Page 1 sur 1
Parser SQL
Publié : jeu. 02/juin/2005 0:28
par 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!
Publié : jeu. 02/juin/2005 6:09
par 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...
Publié : jeu. 02/juin/2005 8:33
par popstatic
et une récursivité pour les requetes imbriquées?
Publié : jeu. 02/juin/2005 9:01
par Progi1984
exact
Publié : jeu. 02/juin/2005 11:10
par 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?
Publié : jeu. 02/juin/2005 11:17
par 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]
Publié : jeu. 02/juin/2005 11:25
par 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
Publié : jeu. 02/juin/2005 11:29
par popstatic
ok c'est bon a savoir, mais alors comment optimiser cette libLDB?
Publié : jeu. 02/juin/2005 11:31
par Progi1984
PS : ce n'est pas la mienne !
Publié : jeu. 02/juin/2005 11:57
par popstatic
arrgh désolé, mais la question tiens toujours!
Publié : jeu. 02/juin/2005 13:02
par 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.
Publié : jeu. 02/juin/2005 13:04
par 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.
Publié : jeu. 02/juin/2005 13:07
par 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