Reprise du message précédent :

Pour ce qui est du curseur je pense que je vais devoir m'interresser à cette solution rapidement car les petits test que j'ai pu faire ne sont pas trés concluant.
J'ai trouvé à peu prés ce que je voulais pour faire mes test, ca s'appelle Webserver Stresstool, y'a une version de démo avec 10 user que j'ai lancé sur plusieurs pc et ca rame pas mal coté serveur (erreur du coté de Webserver Stresstool, mise à jour de la table qui ne se fait pas ...). Donc pas mal de probleme des qu'il y'a plusieurs connection
C'est bien Petit_PimoOosE que tu ai pu voir le getnext sur btrieve, ca permet de mieux comprendre ce que je voulais faire au depart. Btrieve travaille sur un moteur sql c'est pour ca que je pensais qu'il etait possible de faire des getnext en sql. Pour moi un enregistrement suivant ca correspond au tuple, à la ligne (je ne sais pas comment tu preferes) qui vient aprés celle qu'on est en train de lire en tenant compte d'un index.
En gros quand l'index n'est pas du type 1,2,3,4,... mais plutot alphanumérique et sans suite logique, ca permet de suivre le cheminement de l'index sans forcement connaitre sa valeur.

Si je comprends bien, en pratique, c'est l'ordre chronologique des enregistrements qui t'intéresse (je n'ai pas assez creusé pour en être certain...) ?

Dans ce cas, il y a des chances que si tu exécutes sur requête sans ORDER BY, tu tombes sur cet ordre - d'autant plus si tu ne supprimes jamais d'enregistrement. Il vaut mieux que tu fasses des tests quand même.

L'idéal, quand même, serait que tu aies un champ dont le type propose une relation d'ordre (numérique ou non).
Peut-être qu'une solution serait une conversion de ta table en une avec, en plus, un champ autoincrement indexé, ce que te permettrait d'avoir un comportement déterminé. C'est une clé artificielle, ce n'est pas interdit

Juste pour info (qui pourrait toujours être utile), est-ce que la clé de l'enregistrement suivant est calculable à partir de l'enregistrement courant, ou, auparavant, tu faisais confiance à Btrieve pour te sortir la bonne ligne ?

Oui c'est chronologique si c'est une date mais la en l'occurence c'est un index alphanumérique donc c'est par ordre alphabetique. J'ai donc essayé avec > et LIMIT 1 pour avoir l'enregistrement suivant, ca fonctionne seulement on dirait que la requete parcours tout jusqu'a la fin de la base et fait le limit aprés. Et le temps de réponse est donc assez long si on est pas la fin de la base.

Pour la clef artificielle en autoincrement j'y avait pensé comme je le disais dans les post précedent seulement ca va encore alourdir la base, et j'avais peur des temps de réponse la aussi.

La clef n'est pas calculable à partir de l'enregistrement en cours donc je ne peux pas faire un select simple avec une condition sur la clef. Dans Btrieve il n'y a aucun souci de ce coté la, on indique la clef de lecture au départ et quand on fait un getnext ou getprevious il passe d'un enregistrement à l'autre en suivant la clef qu'on lui a indiqué.

Oui c'est chronologique si c'est une date mais la en l'occurence c'est un index alphanumérique donc c'est par ordre alphabetique.

Bon, donc quel que soit la clé (ne parlons pas d'index, c'est pour la suite), il y a une relation d'ordre. Tant mieux.

J'ai donc essayé avec > et LIMIT 1 pour avoir l'enregistrement suivant, ca fonctionne seulement on dirait que la requete parcours tout jusqu'a la fin de la base et fait le limit aprés. Et le temps de réponse est donc assez long si on est pas la fin de la base.

Tu ne m'as pas répondu, mais j'ai peut-être mal posé la question : ta clé est-elle indexée (mise dans un genre de dictionnaire) ? Oui si ta clé est définie comme primaire ou unique, mais si non (pas indexée), c'est normal que toute la base soit parcourue : rien ne garantit la position du premier enregistrement dont la clé répond à la condition. Donc il faut indexer. Et si c'est fait, je parle dans le vent.

Pour la clef artificielle en autoincrement j'y avait pensé comme je le disais dans les post précedent seulement ca va encore alourdir la base, et j'avais peur des temps de réponse la aussi.

Oui... Et non. Parce que ce n'est qu'un petit champ en plus, et qu'avec un peu de chance tu l'as indexé. Mais si ta clé l'est aussi, c'est inutile.

Conclusion : si ce n'est pas fait, crée un index sur le champ de ta clé.

Autre chose : tu auras peut-être intérêt à créer un prepared statement. Ça évitera à MySQL de recompiler et réoptimiser la requête à chaque fois (http://dev.mysql.com/doc/refman/5.1/en/c-api-prepared-statements.html).
Si tu choisis l'option de la procédure stockée, le problème ne devrait même plus se poser : je n'en suis pas sûr, mais il y a des chances que MySQL optimise la requête en compilant la procédure. Et en y repensant, le curseur n'est pas forcément la solution idéale ; le mieux, c'est de tester avec et sans (en utilisant SELECT INTO).


Je suppose que l'index de Btrieve est une notion qu'on peut rapprocher de l'index sur un champ dans MySQL, mais à ma connaissance, on ne pourra pas obtenir exactement le même comportement. Par contre, on devrait pouvoir s'en approcher.

Pour terminer, je te suggère cette lecture que j'ai découverte tantôt (la 1ère et la 2e page sont particulièrement intéressantes dans notre contexte) : http://www.informit.com/articles/article.asp?p=377652&seqNum=1&rl=1

La clef primaire est bien indexée et pourtant la requete est assez longue à s'executer.
Vu les problemes rencontrés j'ai donc crée une clé artificielle autoincrement. Et cela m'a donné une idée. Je ne pouvais pas connaitre exactement la clef de l'enregistrement suivant par contre je peux la localiser à peu prés dans la table. J'ai donc crée une deuxieme table avec seulement 3 champs : 1 autoincrement correspondant à l'autoincrement de la pemiere table et deux champs qui encadrent la clef de la premiere table (je ne sais pas si c'est trés clair )
Avec ca je peux executer ma premiere requete en y rajoutant un between avec les encadrements que je viens de récupérer. Avec ce systeme j'ai virtuellement découpé ma table en morceau de 10000 enregistrements sur laquelle ma requete s'execute bien plus rapidement
C'est un peu de la débrouille mais ca semble résoudre mon probleme de lenteur.
Pour le prepared statement, je suis ouvert à toutes proposition qui pourraient ameliorer la rapidité d'affichage j'ai lu la description et il semblerait que ca augmente la rapidité d'execution meme si les requetes sont éxécutés à des intervales éloignés. Dans mon cas c'est plutot le contraire, il y'aura beaucoup de requetes rapproché et c'est pour ca que j'ai peur des temps de reponse.

Je ne suis pas sûr d'avoir complètement cerné ton idée de la deuxième table, mais ça ne m'a pas l'air fou : si je comprends (~bien), tu limites ton champ de recherche au mieux. Mais alors, ça veut dire que tu actualises cette table à chaque nouvelle requête ?

Pour le prepared statement, "bien accélérer des appels éloignés" ne veut pas nécessairement dire "bien ralentir les autres" ! Le prepared statement, ça précompile une requête, donc ça ne sert à rien si tu n'exécutes qu'une fois cette requête, mais si tu la roules plusieurs milliers de fois, avec juste l'index qui change, c'est merveilleux !
Le mieux, quoi qu'il en soit, c'est que tu testes.

Et n'oublie pas (et pour une fois, tu peux me croire sans inquiétude ) : en optimisation, tu ne peux pas être sûr qu'une solution est pire (ou meilleure) qu'une autre avant de l'essayer. Donc jette aussi un coup d'oeil à la procédure stockée (couplée avec ta deuxième table, ce serait dommage de s'en priver).

Je ne sais pas si je t'aurais tellement aidé au total, mais au moins, j'en aurai appris sur Btrieve...

Oui c'est ca, la deuxieme table me permet de cibler ma requete au mieux, et les temps de reponse on déjà bien diminuer avec cette methode. Elle n'est pas mise à jour mais juste consulter pour aller chercher les encadrement de la clef donc je pense pas que ca prenne beaucoup de temps. Par je me demandais si passer par cette methode revenait au meme que couper sa table reelement pour en faire plusieurs petite ? En gros quelle etait la solution la plus rapide entre faire une requete avec des between sur une enorme table et faire un requete directement sur une table moindre.

Oui en effet j'avais vu aussi que le prepared statement etait utiles dans tous les cas du moment que la requete est lancé plus d'une fois. Don il faudra que je teste tout ca et aussi la procedure stockée pour comparer les performances.

Si si biensur que tu m'a aidé Petit_PimoOosE, je te remercie dailleurs de t'être autant impliqué
Merci aussi à tout ceux qui ont participé au topic
Pour btrieve, j'avais l'habitude de l'utiliser c'est pour ca que je m'etais habitué à ses fonctions mais il reste quand meme moins performant je pense que de travailler directement avec du sql pur vu qu'il est une couche au dessus.

Mais... En fait, est-ce que tu es en train de dire que chaque requête n'a besoin que d'une petite partie fixe des enregistrements ?
En d'autres termes, est-ce que pour une requête donnée, on a un jeu de données précis, et pour un jeu de données donné (muhuhaha), on a une requête précise ?

La requete est la même pour tout les enregistrement de la base mais à chaque fois qu'elle s'execute elle est exécutée seulement sur une partie de la base, d'ou l'utilisation du between que j'avais essayé.
Par contre je suis un peu dégouté pour l'instant, car avant de mettre mon site en ligne et prendre un hebergeur surpportant bcp de connexion, je faisais les test chez free malheuresement leur version de mysql ne prend pas en charge les procédure stockée