Bonjour et merci pour vos interventions respectives.

Au vue de la table, j'ai choisi de faire l'équivalent d'un count bloqué en amont par un confirm.

Le résultat obtenu :
- La moitié de ma page en dur, le "avant" la requête...
- Le confirm par dessus
et en fonction de la réponse le reste de la page qui s'affiche ou la redirection.

En php j'aurai certainement fait autrement étant plus à l'aise mais avec le JSP c'est quand même différent malgré ce que je pensais au départ.

hpl76

Une requête, c'est un trou noir. Entre le moment où tu déclenches la requête et celui où tu récupères le résultat, tu n'as plus la main.

La "longueur" d'exécution de ta requête peut se situer à plusieurs niveaux :
1) au niveau de la clause Where qui n'est pas optimisée avec les jointures, les index, ...
2) au niveau de la constitution du resultset qui peut comporter énormément de données : nombreux champs avec des valeurs très longues.
3) au niveau de la transmission de ce resultset entre le serveur et le poste client

Exemple : une base de données d'images avec beaucoup d'images. La requête peut-être très simple (un simple select sans where), mais si tes images sont dans la base, le niveau 2 de constitution du resultset peut-être très long. Ou si c'est uniquement le path des images qui est dans la base, à ce moment-là, ça peut être le niveau 3 de transmission qui peut être très longue.

Le problème du numrows, c'est que tu ne sais pas si la lenteur provient du niveau 1 ou 2.

Donc question : est-ce que si tu fais une requête select count(*) ... avec la même clause where, est-ce que c'est rapide ou pas ? Si non, il faut optimiser cette clause where ; si oui tu peux donc imaginer un système en deux temps ou trois temps selon le cas :

1) page 1 : tu fais le compte, [b]sans utiliser le num_rows[/b], mais en utilisant une requête select count(*) ... avec la même clause where que la requête de sélection.
2) si le compte est acceptable, tu envoies automatiquement sur la page 2 qui fait la requête et l'affichage (header ('location: ...')
3) sinon, tu envoies un "confirm" qui enverra sur la page 2 si l'utilisateur le choisit

Si tu attends le retour de num_rows, ta requête est déjà effectuée, non ? Mettre un message à ce niveau là me paraît alors superflu.

Dans l'absolu je dirais d'optimiser la requête pour avoir un temps de réponse acceptable dans tous les cas...

Je n'ai jamais eu à créer l'avertissement dont tu parles donc je sais pas trop quoi te dire.

A priori le temps d'attente pour avoir le résultat d'une requête, même sur des champs indexés, peu varié fortement en fonction que les résultats se trouvent en début ou en fin de table ce qui fait qu'il est difficile de savoir le temps que cela prendra avant d'avoir fait l'essai.
En moyenne cela va dépendre de la longueur de ta table et de la complexité de ta requête. A la limite tu pourrais faire un select count(*) sur ta table (sans clause where) ce qui permettra de retourner très rapidement le nombre d'éléments de ta table et d'envoyer ensuite éventuellement un message d'avertissement en fonction du nombre d'éléments de ta table. Si confirmation du visiteur tu fais la requête complète avec les clauses where complètes.

Mais bon le mieux serait encore d'essayer d'optimiser ta requête, ou le schéma de tes tables pour l'accélérer. Peut-être n'as tu pas épuisé toutes les solutions dans ce sens.

C'est comme cela que tu procèdes ou que tu procèderais par exemple AB ?

Merci de ton aide

hpl76

[quote="AB"]Dès que tu fais un affichage javascript ou html c'est que le code php a fini d'être interprété donc il est terminé.[/quote]
Pas mieux :?

m***e, même dans une condition ? Comment peut-on faire ?

Cordialement,

hpl76

Dès que tu fais un affichage javascript ou html c'est que le code php a fini d'être interprété donc il est terminé.

Bonjour,

Je voudrais savoir quelle est la meilleure solution, comment vous feriez pour prévenir que la requête de votre utilisateur risque de prendre du temps.
Je pensais ouvrir une alerte ou un truc du genre et après de proposer dans le même script : voulez-vous vraiment continuer ? et que tout s'enchaine comme si de rien n'était mais ce qui me pose problème c'est de repartir après l'alert...

J'ai utilisé un confirm en javascript. Trouvez-vous cela judicieux ? Si mon num_rows ou la taille de mon array/vecteur est trop grand j'affiche le confirm...

Question sans doute bête :
Est-ce qu'au niveau de l'algo/perf, le serveur est sollicité et continue la moulinette derrière ou bien il s'arrête vraiment tant qu'on n'a pas répondu à la "question javascript" ?

Puis-je avoir votre avis svp merci :wink:

Cordialement,

hpl76