Forum d'entraide PHPFrance

Hello,

J'ai souvent dans une même page plusieurs requêtes à faire sur une même base. Pour le moment et souvent, ma façon de faire est d'effectuer une requête sql qui regroupe tout, puis de mettre le résultat de cette grosse requête dans différents tableaux php, selon la valeur d'un champ.

Par exemple, si un t-uple de ma requête a pour un certain champ la valeur 1, je le met dans le premier tableau, sinon dans le 2e.

Alors, mieux vaut-il faire comme cela, ou mieux vaut-il faire plusieurs requêtes ? En résumé la question c'est est-ce que le temps gagné à accéder à la base de donnée en faisant une seule grosse requête est suffisamment significatif pour se permettre ensuite de subdiviser cette grosse requete dans des tableaux php ?

Merci de votre réponse !

Il y a des fonctionnalité sous mysql qui permettent de tester le temps d'execution d'une requete.

Tu prends quelques exemple, tu compares le temps d'execution d'une grosse requete avec celui de plusieurs petites additionnées.
La tu peux voir le plus rapide.

Il faut aussi savoir qu'une grosse requete va te bloquer un thread mysql jusqu'a ce qu'elle finisse alors que les petites les libereront plus vite.
Donc à temps d'execution egal, il vaut même mieux avoir des petites requêtes.

Il faut faire des tests jusqu'à ce qu'on ait une idée générale qu'on n'acquiert qu'avec de l'experience.

sous MYSQL 5.0 on utilise

show status like 'last_query_cost'

il te donnera le tps d'execution de ta dernière requete.

PS: tu peux utiliser des requetes explain $requete au lieu de lancer $requete directement avant d'utiliser la commande

show status like 'last_query_cost'

Pour continuer l'optimisation du temps d'exécution, n'oublie pas de vérifier la bonne utilisation des indices (explain te les montrera), de ne sélectionner que les données dont tu as effectivement besoin, d'utiliser les jointures avec bon escient, etc..

Le meilleur moyen pour obtenir des certitudes, c'est bien sur de chronométrer le temps d'exécution de ton script.

Mère teresa te répondrait que :

La taille compte

Je la laisse développer...

En général, n petites requêtes prennent plus de temps qu'une grosse.
Et comme tu l'as présenté le découpage ne semble pas exceptionnel donc bon…

Une grosse requête peut être gourmande en ressource mémoire... donc dépend aussi des éventuelles jointures.

... mais pour des cas "basiques", comme dit Sékil : "n petites requêtes prennent plus de temps qu'une grosse".

Evidemment comme mentionné plus haut le verdict est dans les bench, on a pas assez d'info pour te donner une réponse plus précise.

En général, n petites requêtes prennent plus de temps qu'une grosse.
Et comme tu l'as présenté le découpage ne semble pas exceptionnel donc bon…

Ah non mais le découpage que j'ai présenté, c'est le découpage que je fais à partir de la grosse requête !

Je fais ma (grosse) requête, je récupère le tout dans un tableau, puis je parcours ce tableau pour stocker tel t-uple dans un tableau, tel t-uple dans un autre. Après je me sers des tableaux que je crée ainsi quand j'en est besoin.

Enfin bref, c'est peut-etre pas méga clair, mais de toute façon la conclusion ... c'est de faire des benchs

merci de l'aide !

Non, non, j'ai compris que tu parlais de cela, mais cela explique le découpage que tu ferais pour diviser en n requêtes. Si tu n'utilises pas l'UNION, et que tu n'as pas 50 JOIN, il n'y a aucune raison de vouloir découper cela.
Dans ton cas, j'imagine que tu récupères toutes les données d'une table par exemple, et qu'ensuite tu les classes. Et ça, je suis désolé mais ya pas de raison de découper. Ce qu'il est important de voir, c'ets que tu peux facilement avoir toutes les données du premier coup, et ça c'est bien mieux.

Dans ton cas, j'imagine que tu récupères toutes les données d'une table par exemple, et qu'ensuite tu les classes. Et ça, je suis désolé mais ya pas de raison de découper. Ce qu'il est important de voir, c'ets que tu peux facilement avoir toutes les données du premier coup, et ça c'est bien mieux.

Ah ouais ok, alors tu m'avais bien compris, c'est exactement ça. Beh merci de l'avis, il me reste plus qu'a regarder le temps d'exécution