Discussion :

[sabotage]

Bonjour,

Il m'est venu une question :
vaut-il mieux faire une grosse requete et l'analyser en php
ou
vaut-il mieux faire de multiples requetes

j'ai donc mesuré le temps sur 1000 iterations de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
$liste = array(0=>4, 1=>7, 2=>2, 3=>14);
 
foreach ($liste as $value) {
	$sql = 'SELECT nom FROM clients WHERE idx =' . $value;
	$res = mysql_query($sql);
	while ($data = mysql_fetch_array($res)) {
		echo $data["nom"]
	}
}

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
foreach ($liste as $value) {
$in_liste .= $value . ",";
	}
 
$in_liste = substr($in_liste,0,-1); // on retire la derniere virgule
 
$sql = 'SELECT nom from clients WHERE idx IN (' . $in_liste . ')';
$res = mysql_query($sql);
 
while ($data = mysql_fetch_array($res)) {
	echo $data['nom'];
	}

Le resultat est très nettement en faveur du cas 1 (interrogation multiples de la bdd) mais le point lent du cas 2 semble être tout betement la construction de la $in_liste ...

Globalement quelle méthode utilisez-vous ?
La méthode 1 donne un code beaucoup plus simpe mais provoque des interrogations repetées de la bdd.

Est-ce que mon test est biaisé parce j'aurais mal construit mon cas 2 ?

Merci pour vos reponses.

[FCYPBA]

Bonjour,

pour ma part, les test ne sont pas significatifs en raison de la non complexité des requêtes ( avec les bons indexs, les deux peuvent presque être aussi rapide. ) , et comme tu l'as si bien remarqué, le temps perdu dans le deuxième cas provient à mon avis de la fabrication de la liste de valeurs.

Pour ton teste 2, essaie d'utiliser les fonctions php faites pour la concaténation de tableaux. implode() est fait pour ca.


D'une manière générale, une requête même volumineuse vaudra toujours mieux que 1000 petites. Dans les systèmes en production, les serveurs web et BDD sont le plus souvent situé sur des machines distinctes ce qui engendre du dialogue entre celles-ci. En n'effectuant qu'une seule requête, tu réduis déjà ce point. De plus, avec plein de requêtes, le serveur sera chargé pendant un plus grand laps de temps, sauf si la requête unique est vraiment lourde.

[Alain Defrance]

Je répond sans hésitation qu'il vaut mieux faire travailler le SGBD plutôt que coder ce que le SGBD sais déjà très bien faire
De plus, plus tu fait travailler le SGBD et moins tu travail toi (avec l'utilisation des contraintes, triggers et procédures stockées le travail du SGBD peut représenter un travail énorme.

[romain_ci]

Je répond sans hésitation qu'il vaut mieux faire travailler le SGBD plutôt que coder ce que le SGBD sais déjà très bien faire
De plus, plus tu fait travailler le SGBD et moins tu travail toi (avec l'utilisation des contraintes, triggers et procédures stockées le travail du SGBD peut représenter un travail énorme.

Tu travail peut etre moin mais le jour ou il y a 4000 ligne en BDD la ton appli va un peu galerer....

Il vaut mieu travailler avec PHP et separer tes requetes, sans l'ombre d'un doute !

[FCYPBA]

Tu travail peut être moins mais le jour ou il y a 4000 ligne en BDD la ton appli va un peu galerer....

Il vaut mieux travailler avec PHP et séparer tes requêtes, sans l'ombre d'un doute !

Là je suis pas d'accord, et j'attends avec impatience tes explications. ( 4000 lignes renvoyées ou dans la table ? )

Le point bloquant est presque toujours la bdd c'est vrai, mais ce n'est pas en la noyant sous les requêtes que cela va la sauver.

Le moteur de base de données s'est de lui même faire beaucoup d'optimisation que tu ne feras pas dans ton code php.
Ensuite, les index pourront permettre d'optimiser encore plus les requêtes, il faut juste surveiller que le moteur les utilise.

Plus vite tu auras récupérer les datas dans ton php, plus vite ton serveur bdd sera dispo pour la requête d'un autre utilisateur.

[Alain Defrance]

D'accord avec toi FCYPBA, il ne faut pas oublier que les SGBD ont pour travail de gerer des données ainsi que d'optimiser leurs acces, alors il le fera toujours mieu qu'un programmeur.
Le programmeur à pour role de relier les données à un IHM et de demander le plus d'informations a la fois au sgbd pour lui eviter plusieurs traitement de requetes.

Ensuite 4000 lignes pour un sgbd c'est absolument rien. tu exporte tout ca en moins d'une demi seconde ... en revenche je veux bien chronometrer la vitesse de ton algorythme pour le traitement du meme nombre de donnée.
Ne pas oublier que le modèle merisien (référence en terme de base de donnée relationelle) préconise de séparer au maximum les données, ceci implique pas mal de tables servant seulement a lier des tables, et comportent souvent beaucoup d'occurences composé en majorité d'identifiant. Il y a beaucoup d'occurence non porteuse de donnée, mais indispensable a une bonne organisation des données.
La vitesse d'une base de donnée ne depend pas toujours (et meme rarement) de sa taille mais de son organisation (indexation, structure des tables, etc ...)

Pour finir en matière de resource système, souvent (dans l'hebergement web) le sgbd et apache sont sur la meme machine, alors si tu prend pas en compte que le sgbd travaille mieu que toi, sache que si ta machine effectu moins de calculs pour le sgbd, elle en dépensera plus pour ton apache ...

[s.n.a.f.u]

Bonjour,

pour ma part, les test ne sont pas significatifs en raison de la non complexité des requêtes ( avec les bons indexs, les deux peuvent presque être aussi rapide. )

Je ne crois pas : un WHERE id = ... sera quasiment toujours plus performant qu'un WHERE id IN ...

D'une manière générale, une requête même volumineuse vaudra toujours mieux que 1000 petites.

Ca dépend trop des indexes et des jointures éventuelles entre tables pour pouvoir faire une généralité.

Dans les systèmes en production, les serveurs web et BDD sont le plus souvent situé sur des machines distinctes ce qui engendre du dialogue entre celles-ci. En n'effectuant qu'une seule requête, tu réduis déjà ce point. De plus, avec plein de requêtes, le serveur sera chargé pendant un plus grand laps de temps,

La grosse requête peut aussi exploser la RAM si elle est éxécutée par plusieurs visiteurs simultanément.

sauf si la requête unique est vraiment lourde.

bah oui...

Tout ça pour dire que ce que tu dis est vrai, FCYPBA, mais je te trouvais juste un peu catégorique...