Discussion :

[speedev]

Bonjour,

Je me demandais, d'un point de vue organisation du code / performance, s'il est préférable de rassembler un maximum de résultats dans une grosse requête SQL ou de les dispatcher dans de petites requêtes plus facilement réutilisables dans un projet...

Vous allez me dire que ça dépend des résultats et de leur exploitation dans le code ("réutilisabilité" etc...) et c'est vrai, mais je me pose de plus en plus souvent cette question quand je m'apprête à faire une requête et j'ai tendance à partir vers la requête très complète qui m'évitera d'avoir trop de requêtes à gérer. Mais finalement si je gagne en performance, est-ce-que je ne manque pas d'optimisation en faisant cela...

L'idéal c'est de lire les expérimentés !

Merci !

[mon_nom_est_personne]

De mon point de vue plus on laisse la base de donnee travailler le mieux c'est. Car ta db sera toujours plus rapide, plus performant que ton script et t'as l'air plus cool. Biensur plus la requete deviens complexe et plus faut etre bon en sql et savoir fair le mariole avec les stored procedures, view etc...
En plus cette question tombe super bien j'etais entrain d'en debattre avec un college qui lui recommander une approche plus logiciel. On a comparer avec la requete la plus compliquee qu'on ai pu imaginer sur le plus gros jeu de donnees qu'on avait. Resultat :
- gros sql = 4s
- plein de petite avec des boucles etc... = 10s sans parler de la charger server etc...

encore une fois, sql win

[darkstar123456]

De mon point de vue plus on laisse la base de donnee travailler le mieux c'est. Car ta db sera toujours plus rapide, plus performant que ton script et t'as l'air plus cool. Biensur plus la requete deviens complexe et plus faut etre bon en sql et savoir fair le mariole avec les stored procedures, view etc...
En plus cette question tombe super bien j'etais entrain d'en debattre avec un college qui lui recommander une approche plus logiciel. On a comparer avec la requete la plus compliquee qu'on ai pu imaginer sur le plus gros jeu de donnees qu'on avait. Resultat :
- gros sql = 4s
- plein de petite avec des boucles etc... = 10s sans parler de la charger server etc...

encore une fois, sql win

Plusieurs petites requetes sont bien mieux qu'une grosse. Je sais de quoi je parle je crée des sites sur les quels il y a plusieurs dizaines de milliers de personnes qui passent chaque jour et je peux t'assurer que les LEFT JOIN les serveurs aiment pas bien ça

(Apres ça dépend des requêtes aussi, dans certains cas un JOIN donnera de meilleures perfs mais c'est assez rare et quoi qu'il arrive : ne jamais dépasser UN seul JOIN, ajouter autant d'INDEX que possible et chercher avec un maximum de WHERE pour limiter les recherches, et pour les dates => préférer une date en dur plutot qu'un NOW())

[onet]

Ca dépends. Il n'y a pas de règle absolue.

Petite exemple: Une grosse requete qui prends 4s signifie que durant 4s (!!! c'est une éternité en programmation !!!), ta table sera lockée, et qu'un script la monopolisera.

Perso, je n'ai pas le droit de me le permettre, sur certains sites (et la, je te parle de milliers de visiteurs en simultané). C'est pour cela que dans certains cas, il est nécessaire d'optimiser ses tables, différer certaines mises à jours qui peuvent etre faite, utiliser des tables en memory avec des trigger pour mettre à jour en // une table physique, etc...

Après, il y a certaines fonctions à éviter (le IN est une aberration en optimisation, de manière générale), ou à privilégier (un & binaire est +1000 fois plus rapide qu'un IN, et 10x plus rapide qu'un = par exemple).

Il est aussi intéressant d'éviter de faire un rand + limit 10 par exemple, car le rand va de tout facon devoir lire toute ta table. Si par exemple tu as des requetes qui reviennent souvent, tu peux très bien faire un select de l'entier de tes données, et faire le rand en PHP. Pourquoi? Car la première requete sera certe très lente, mais les suivantes instantanéée, car Mysql les retrouver dans son cache.

Ce qui me permets de citer le prochain point: bien configurer son cache MySQL. C'est un gain de temps énorme dans certains cas de figure, etc...

Bref, les pistes sont énorme. On ne peux pas dire qu'une grosse requete soit mieux que 10 petites, dans tout les cas (coté temps global, 10 petites seront plus lente, car il y aura 10 aller-retour php - mysql. Par contre avec une seule grosse, ta base peut etre lockée durant un temps non négligeable, pouvant faire tomber le serveur par effet boule de neige).

Onet

[BobLunique]

Surtout que si ton serveur SQL n'est pas sur le même serveur que ton application, tu as le transit réseau en plus ...

Le truc a lire pour avoir un serveur mysql qui distribue les resultats plus vite :
http://dev.mysql.com/doc/refman/5.1/en/query-cache.html


Du coup, perso, je vote pour 1 grosse requete BIEN FAITE.


PS:


Puis apres, si tu fais 10 requetes, puis qu'un jour, tu veux optimiser avec un vrai outil... comme memcache par exemple... eh bien il faudra que tu rajoute 10 fois 4 lignes de codes ... et tu te retrouvera avec un espèce de plat de nouille que personne ne veut relire....
( car si tu fais un truc pourrit a chaque fois pour ne pas faire de jointures ou d'union, ton code va vite grossir inutilement, et il deviendra de moins en moins propre )

http://www.danga.com/memcached/

[speedev]

Ok merci.