Reprise du message précédent :

Et ces quoi ces conditions d'arrêt qui ne peuvent pas être incluse dans le WHERE ?

Oula toute ces reponses d'un coup

En reponse à Loading : faire un tableau avec un index et ma clef primaire serait une idée mais la taille de la base est trop grosse pour faire ca.
En reponse à Woofy : c'est un script sur une table de statistiques et proba. d'ou la taille de la base et le fait qu'il n'y ai pas de dba Et quand j'ai crée la base je n'ai pas voulu mettre un autoincrement car je savais qu'il y'aurai beaucoup d'enregistrement, seulement je ne pensais pas que j'allais autant galerer derriere
En reponse à Erel69 : dans chaque enregistrement y'a plusieur champs binaire numérotés 1,2,3,... qui correspondent à un tableau et en gros à chaque fois que j'arrive sur un enregistrement, je fais une boucle pour lire chaque valeur du tableau et si y'en a un à False je sors de la boucle et je renvoi la clef primaire sinon je continue. Si j'arrive à la fin du tableau en trouvant que des True c'est la que je veux passer à l'enregistrement suivant.

Bah un SELECT ... FROM ... WHERE 1==false OR 2== false OR 3==false... LIMIT 1

Comme ça tu aura le premier enregistrement où l'un des champ binaire est a false (enfin requête a adapter un peu mais le principe y est).

Oui en effet c'est une solution, je voulais eviter une requete enorme (c'est un gros tableau) comme ca parce je ne sais pas ce que ca peut donner niveau temps de reponse sur une grosse base.
Et je pensais aussi qu'il existait une maniere simple de passer d'un enregistrement à l'autre mais apparement non

Merci en tout cas Woofy je vais faire comme ca

Ben disons que une grosse requête comme ça avec beaucoup de conditions mettra beaucoup moins de temps qu'un million de requête !
Il vaut mieux faire comme ça !

Je partage l'avis de Woofy, d'autant plus qu'il est bien possible que le driver soit capable d'optimiser d'une manière ou d'une autre le rapatriement des résultats.
mysql_fetch_row() donc.

Sinon, tu peux aussi faire une procédure stockée (qui commencent à être supportées à partir de MySQL 5.1), ce qui permet de minimiser le boulot de tout le monde (le seveur bosse un peu plus, mais il n'a pas à t'envoyer les millions d'enregistrements - et le client n'a pas à les recevoir).

Le 24 janvier 2007 - 12 h 40, Woofy a écrit : Bah un SELECT ... FROM ... WHERE 1==false OR 2== false OR 3==false... LIMIT 1 Comme ça tu aura le premier enregistrement où l'un des champ binaire est a false (enfin requête a adapter un peu mais le principe y est).

Je vois pas comment ca peut fonctionner si les champs sont de type binaire et contiennent un tableau, et que la condition d'arrêt soit qu'une valeur du tableau soit à FALSE

Ah oui, j'ai confondu BINAIRE et BOOLEEN !
En même temps, faire une requête sur un champ binaire sur des miliers d'enregistrement, j'espère qu'il n'est pas pressé !

Oui desolé je me suis trompé dans les termes
C'est un tableau de booleen !
Donc j'ai fait qu'une seule requete, et ca n'a pas l'air trop lent pour l'instant, seulement il faudrait que je teste avec plusieurs utilisateurs qui accede en meme temps à la base. Est ce que vous connaissez un outil qui permet de simuler ca, parametrer un nombre d'ulisateurs accedant à la page et qui me dit en combien de temps la page s'affiche ?

En même temps, une requête simple "SELECT ... FROM ... WHERE" sans jointures, je pense qu'il n'y a pas plus rapide.

J'étais sérieux, avec mon histoire de procédure stockée, hein ! (à moins que MySQL 5 ne soit pas une option)

Je sais pas faire une procédure stockée. Tu fais comment ?

Moi non plus

Il se peut que tu ne puisses pas encore faire tout ce que tu veux, mais... La référence est ici (v5.1) : http://dev.mysql.com/doc/refman/5.1/en/stored-procedures.html
(les user comments sont intéressants aussi !, et il y a une VF de la doc).
Concrètement, une procédure stockée est une programme - une fonction - codée dans un langage qui est une extension du SQL. Ce programme est compilé et exécuté directement par le SGBD.

Ça peut être utilisé par le serveur quand on utilise des triggers, ou par le client qui peut y faire appel par du simple SQL (il faut que je retrouve la syntaxe, mais tout est sur le site de MySQL).

Merci !

PS : tu a largement depasse ton quota de post semestriel Qu'est-ce qu'il se passe pour que tu passe si souvent ? On te manquait ?

Bon, c'est idiot, je ne retrouve plus comment on fait EXACTEMENT.

Je crois qu'il faut faire mysql_query( requete ), avec requete pouvant valoir:
- "call maprocedure(arg1,arg2)"
- "exec maprocedure(arg1,arg2)"
- ou tout simplement "maprocedure(arg1,arg2)".
Ça m'apprendra à faire le malin.

woofy> mon absence du forum a créé comme un vide dans ma vie, je me sentais inutile . Promis, je recommencerai pas !
Et puis le SQL, ça change un peu de l'assembleur...

Merci pour ces infos Petit_PimoOosE je regarderais de ce coté la si c'est vraiment trop lent. Justement je pour l'instant je cherche à tester l'efficacité de la requete que j'ai faites à partir de vos conseil. Je cherche un outils qui pourrait simuler un max de connexions (bon par contre j'ai peur que l'hebergeur n'apprecie pas trop )
Mais si vous connaissez un soft dans ce genre la faites le moi savoir, ca me permettra de tester sur un réseau local déjà.

Si tu est ok pour faire une procédure stockée, les curseurs semblent être la meilleure solution à ton problème.

Ils sont fait pour passer en revue les enregistrements retournés par une requête, un par un.

J'utilisais fréquemment ça sous oracle avec des procédures stockées en PL/SQL, très pratique.

Voir la doc mysql.

J'appuie DeVice sur les curseurs.
Pour tes tests de charge, d'abord et à mon avis, il faut que tu évalues une charge typique. Est-ce que tu t'attends à ce que 2, 10, 100 utilisateurs fassent la même requête en même temps ?

Parce que ce n'est pas la peine de mettre ton serveur à genoux si tu sais qu'en moyenne 10 personnes par jour afficheront ta page. Si par contre c'est plus souvent et qu'en plus tu as des contraintes de temps sur d'autres requêtes, là, il va falloir réfléchir plus sérieusement au moment d'étudier une solution.

Je n'ai pas de réponse complète ni professionnelle, mais une solution (très) simple est de faire faire le test par un script, mettons Perl ou Python, qui pourrait lancer x requêtes en même temps dans des threads séparées, possiblement sur des connexions et utilisateurs différents, puis attendre que tout le monde ait fini pour voir le temps que ça a pris.
Il faut aussi envisager d'autres scénarios, comme envoyer cette requête plusieurs fois avec un petit délai (mais avec chevauchement), mais aussi d'autres requêtes courantes en même temps.

Bref, l'idéal est que tu arrives à reproduire une situation réelle ou un peu plus exigeante, mais ça ne devrait pas être compliqué.

Une fois que tu as des mesures, et selon le degré d'accès au serveur que tu as, tu peux aussi relever des compteurs maintenus par MySQL via la ligne de commande ou un outil comme MySQL Administrator, pour voir qu'est-ce qui prend du temps.

Une fois que tu as bien déterminé d'où vient le problème, tu peux commencer à optimiser ton affaire.

Tiens, en passant, je suis allé chercher ce que c'était que Btrieve.
À ce que j'ai compris, si le getnext() existe sous ce système, c'est à cause de sa philosophie.

Sous MySQL (et autres SGBDR), il n'y a pas vraiment de notion de "prochain enregistrement". C'est toujours selon un critère particulier. En fait, en théorie (mais peu probable), d'une requête à l'autre, si tu ne précises pas de ORDER BY, tu pourrais très bien récupérer tes données dans un ordre différent... Et les tables ne sont pas obligées d'être dans des fichiers, ça pourrait très bien tout être un gros bloc mémoire ou des clusters alloués en forme de dinosaure sur un CD.

C'est quoi, pour toi, un enregistrement suivant ?

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.