Discussion :

[courdi95]

Bonjour

J'ai une base hfsql c/s qui contient plusieurs millions d'enregistrements. Chaque enregistrement a un id unique de 20 caracteres.

La recherche d'un enr avec la commande hlitrecherchepremier prend énormément de tems. A votre avis est il possible d'optimiser la vitesse de recherche en decoupant la cle unique, et en creant une cle composee puis en faisant un hlitrecherche sur cette cle ? La dichotomie se ferait sur les differents morceaux automatiquement ?

Ouen faisajt une suite de requetes imbriquees avec successivement les differents morceaux de la cle ?

A votre avis est ce que cela va ameliorer la rapidite ?


Si vous avez d'autres pistes, ne pas hesitez a me les communiquer.

[hpascal]

Bonjour

Et passer par une requête SQL ce n'est pas plus rapide ?
Je te conseille vraiment d'utiliser HLitRecherche, c'est une catastrophe sur des grosses tables.

C'est courageux d'attaquer des volumes pareils avec HyperFile ...

[courdi95]

La réponse m'amène à poser des questions complémentaires :

1. pour se positionner un enregistrement afin de le modifier, comment faire sans utiliser HLitRecherchePremier ? une requête va me renvoyer les infos sur l'enregistrement en question mais sans me positionner sur l'enregistrement dans le fichier pour faire un HModifie ... à moins que je n'ai loupé quelque chose ?

2. dans le cas d'une requête sur HFSQL C/S que vaut-il mieux faire : HExecuteRequete ou HExecuteRequeteSQL ?

3. HyperFileSQL est tout de même une base professionnelle ?!? et au TDF ils font des démos sur une base HFSQL C/S avec des milliards d'enregistrements .... est-ce que MySQL serait mieux placée ? ... quels sont les réels défauts de HyperFileSQL C/S ?

[hpascal]

1 : L'équivalent du HModifie est une requête UPDATE
Certes les fonctions H... sont très simples à utiliser et je comprend cet argument.
Mais au niveau performance il n'y a pas photo.
ça m'arrive cependant d'utiliser des ordre H.. sur des petits fichiers (paramètres, ...) et c'est qu'on HAjoute est plus pratique qu'une requête INSERT.
Mais c'est une question d'habitude et après on va très vite en SQL et on maitrise mieux le comportement du programme.

2 : Sur HF c'est pareil, si ce n'est que qu'avec HExecuteRequeteSQL tu écris ta requête dans le code alors que l'autre utilise un "objet" requête graphique à la sauce PCSOFT. Pour d'autres bases par contre ce n'est pas la même histoire car certaines syntaxes ne sont pas acceptées par Windev et on doit passer par HExecuteRequeteSQL avec l'option hSansCorrection

3 - Le TDF est une présentation commerciale. Le test est fait sur un fichier avec une clé unique numérique et j'imagine sur une machine de guerre.
Le problème c'est qu'Hyperfile s'effondre dès qu'on commence à utiliser plusieurs tables dans des requêtes et particulièrement en réseau.
Fais quelques recherches dans ce forum, tu comprendras.
Maintenant je ne dis pas que c'est une mauvaise base mais il existe d'autres bases (dont des gratuites, comme PostgreSQL) beaucoup plus performantes et avec beaucoup plus de possibilités au nouveau du SQL. Quand on pense qu'il y a peu de temps encore on ne pouvait pas mettre plus d'une jointure gauche dans une requête avec HF ... (je crois que c'est résolu)

[courdi95]

Merci pour ces témoignages et pistes :

1. Donc si je comprends bien, il vaut mieux faire une requête du style (créée avec l'éditeur de requête de windev)

Code :

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

1
2
3
4
5
6
7
8
 
UPDATE 
	mon_fichier
SET
	valeur 1 = {param_valeur1},	
	valeur 2 = {param_valeur2}
WHERE 
	mon_fichier.ID = {param_ID}

plutôt que

Code :

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

1
2
3
4
5
 
HLitRecherchePremier (mon_fichier,ID,param_ID)
mon_fichier.valeur1 = param_valeur1
mon_fichier.valeur2 = param_valeur2
Hmodifie(mon_fichier)

?

2. Et pour les performances qu'est ce qui est mieux ? HexecuteRequete ou HexecuteRequeteSQL, pour une base HFSQL C/S ?

3. Bien noté. Dommage. Et MySQL ? par rapport à PostgreSQL ? Le point est que nous avons un hébergement (bien pratique) chez Kalanda.net (Webdev + HFSQL C/S). Il faudrait changer d'hébergeur pour la base ?

[hpascal]

1 - oui
2 - c'est pareil
3 - MySql c'est très bien aussi, en tout cas meilleur que HF

MySql et PostgreSQL étant gratuits, je te conseille de faire tes propres tests (en local pour commencer) pour comparer avec HF

Bonne soirée

[courdi95]

3. Est ce qu'il existe un comparatif argumenté avec des mesures entre hfsqlcs, mysql ou postgresql? Avant de me lancer dans un changement de base, je voudrais d'autres arguments que 'hyperfile c'est pas bien'. Est ce que ce genre de doc existe ?

[hpascal]

Un comparatif ça m'étonnerait, PCSOFT ne le permettrait pas
Mais tu as raison et c'est bien pour ça que tu dois faire tes propres tests
Chacun donne son avis ou vécu en fonction de son contexte qui est n'est peut être pas du tout le tien
De mon coté lorsque j’utilisais HF c'était la version Classic et pas la version C/S. A l'époque c'était une catastrophe en réseau.
Mais HF évolue et s'améliore d'année en année et des logiciels professionnels l'utilisent

[courdi95]

Merci pour ta contribution. Je vais contacter pcsoft directement pour avoir leurs recommandations.

[DelphiManiac]

Pour une fois je vais défendre Windev

Par acquis de conscience, je viens de faire le test sur une table HF C/S toute simple de 4110000 enregistrements. La clé est une clé alpha unique de 20 caractères. Pour effectuer 5000 recherches, ça tourne aux alentour de 600 millisecondes.

Le client et le serveur sont sur le même poste. En réseau, cela va rajouter du temps c'est un fait.

Jusque là, on peut pas dire qu'il y ai de grosses lenteurs.

Concernant ta demande initiale, la recherche dichotomique; le principe d'un index B-TREE est justement un principe approchant de la recherche dichotomique et il n'y a pas plus rapide à ma connaissance.

Les questions :
- Qu'entend tu par lent ?
- Quelle est la taille réelle de la base ?
- Quel environnement, poste seul ? réseau ? de quelle vitesse ?

La question très bête (mais on ne sais jamais) :
- Ton champ est-il bien indexé ?