salut
 
j'ai un souci plutot incomprehensible a vous soumettre :
 
j'ai une requete qui interroge une table qui fait un peu moins de 80000 enregistrements.
 
traitement normal de l'operation :  
 

 
TEMPS de l'operation : 0.07 secondes
 
maintenant, si j'ajoute un ORDER BY chp2 DESC, mon temps d'execution monte a plus de 10 secondes !!!
 
expliquez moi ce qui ne va pas svp, je craque severe ...

quel SGBD utilises tu pour être obligé de passer par ODBC ?

et puis bon, trier une table de 80000 enregistrements, ça se fait pas forcément de façon instantanée non plus

j'utilise MSSQL server 2000 sur un Win2000 server
la table fait 80000 enregistrements mais le resultat de la requete n'en comporte que 28 lui ...  
 

Ben faut faire des indexes un peu

y'en a justement ...
 
mais les index ne devraient jouer que sur le odbc_exec, pas sur le temps d'execution du odbc_fetch_row non ??
 
perso, je comprends vraiment pas prq un ordre de tri peut mettre aussi longtemps ... je fais le meme type de requete sur des tables 2 a 3 fois + grosses et ca marche parfaitement ...

et le champ en question a un index ?
 
edit:

je connais peu SQL Server, mais peut etre est il possible que le ORDER BY soit fait sur la table entière, et non sur l'échantillon ?
un très ancien SGBD utilisait ce procédé il me semble (BTrieve pour ne pas le nommer)

je ne peux pas te repondre sur ce point
 
mais comme je l'ai dit, je fais ce type de requete sur d'autres tables + lourdes et ca passe nickel ...
 
je ne pensais pas avoir de pb sur ce genre de trucs aussi "basiques" ...

Non non, SQL Server fait le order by sur le résultat.
 
Par contre, vérifie les paramètres ODBC (y'a une chiée de paramètres que tu peux initialiser depuis le code normalement) et vérifié que le order by et le filtre ne sont pas fait côté client. Ca m'étonne, mais bon. (avec ODBC, on peut bosser de façon transactionnelle sur une copie de la table en local, et pour transfèrer 80000 lignes vers le PHP, ça pourrait bien mettre ces 10 secondes...)

tu peux me donner une piste pour ODBC ? je ne l'utilise que pour declarer mes bases alors je ne sais pas ce qui est parametrable et ce qui ne l'est pas ...
 
mais ce qu'il y a c'est que je fais ce même "traitement" sur d'autres tables, parfois + lourdes encore et ca passe toujours comme il faut ...
 
merci deja de vous etre interesse a mon cas

Ben je peux pas du tout t'aider à ce niveau en PHP. Je ne fais que de l'ASP.
 
Mais grossomodo, avec l'ASP, quand tu as un recordset (lorsque tu utilises les bibliothèques MSADO, qui contiennent entre autre le support ODBC) il y a des propriétés telles que CursorLocation, CursorType, LockType qui permettent d'indiquer si le curseur est côté serveur ou côté client, s'il est en mode connecté ou déconnecté, et s'il verouille les lignes de la base ou non. Ca permet entre autre de créer des lignes ou de les mettre en jour directement dans l'objet, sans avoir à effectuer la moindre requête.
Il y a aussi des propriétés à l'objet Command, qui contient la requête, tels que Filter ou Sort, qui permettent d'effectuer des filtres et des tris. Lorsqu'on bosse en mode client, avec une connection active par exemple, le order by et les conditions sont recopiés dans ces objets "filter" et "sort", afin de pouvoir les modifier dynamiquement côté client. Et ceci a évidement un coût, car il faut effectuer une copie complète de la table en mémoire.

 
Nan, là rien à voir le client sait rien faire.
Mais j'ai pas d'explication, ordonner 28 lignes, même sur 486 c'est quasi instantanné.
Fous-toi (heu onano, MagicBuzz il s'en fout, c'est pas son pb) dans une console SQL et regarde un DESC de ta requête pour voir comment il réduit ça, il doit y avoir un truc pas catho (une connerie sur le type d'index par ex.).

 
merci de votre aide
 
nraynaud : dans l'analyseur de requete, tout se passe bien, tout comme mon odbc_exec sous PHP (si je ne me trompe pas, cela correspond a la meme chose non ?)
 
c'est lors de mon odbc_fetch_row que ca rame et ca, je vois pas comment le faire dans l'analyseur ...

je viens de tester apres avoir supprime mes index : je divise par 5 le temps d'execution !  
 
vous comprenez quelque chose vous ?