[DEBAT] fonctions Mysql vs fonctions PHP [Résolu]

[gisele]

Salut à tous,

Je me demandais si parmi vous ils y en auraient des arguments ou expériences en faveur du formatage d'une date au niveau du serveur Mysql dans la requete , ou a contrario en faveur du traitement en PHP du jeu d'enregistrement via des fonctions comme date().

en gros c'est quoi le préférable et dans quelles conditions (disons pour une machine mixte, ou a ressources égales si serveurs SQL et serveur web sont sur 2 machines distinctes) entre

Code :

1
2
3
4
5
 
$SQL = "SELECT FROM_UNIXTIME(MON_CHAMP_TIMESTAMP, 'mon formatage')  ...
[...]
while($data = mysql_fetch_row....)
   print $data[0];

ou

Code :

1
2
3
4
5
 
$SQL = "SELECT MON_CHAMP_TIMESTAMP  ...
[...]
while($data = mysql_fetch_row....)
   print date('formatage', $data[0]);

Plus généralement je souheiterai savoir dans quels cas vous utilisez les fonction mysql et dans quels cas vous préférer les fonctions PHP.

[Bidouille]

Cela a des répercussions si tu fais des calculs sur les champs date.
La charge incombera soit au serveur web, soit à la base.

[gisele]

Salut Bidouille,

oui je me doute, c'est pour cela que j'ai précisé "pour une machine mixte, ou a ressources égales si serveurs SQL et serveur web sont sur 2 machines distinctes".

Mais puisque tu vas sur ce terrain justement à ressources égales, vaut-il mieux charger le serveur SQL ou le serveur web?
Je pense que pour cette question la fiabilité et la performance pures des fonctions doit être déterminante (toujours indépendemment des ressources des serveurs).

Pour ma part je vais tacher d'expérimenter des benchs de comparaison de méthode du genre ci-dessus (FROM_UNIXTIME vs DATE), dans des conditions ou aucun différentiel de ressources machine ne viendra parasiter l'interprétation.
Le mieux c'est de faire ça dans des condition ou tout est en local sur une même machine.

Peut être passerai-je néanmoins à coté d'une d'éventuels facteurs déterminants comme les contraintes de communication entre 2 machines (bande bassante etc.) ou l'une des méthode pourrait se montrer à son avantage selon qu'elle induira plus ou moins de flux entre les 2 machines...

Bref je vous tiens au courant, et vos avis seront les bien venus.

[yiannis]

Bonjour,

J'avoue que j'utilise au maximum les fonction mysql dans mes query pour eviter de faire du traitement php (ex: format de date, calcul de unix_timestamp etc)
Maintenant est ce que c'est mieux? Je ne pourrais te dire car je n'ai fait aucun bench, mais je me dis pourquoi faire un explode sur une date alors que mysql le fait avec le date_format
Au sujet des performances, compare a un autre developpeur (a cote de moi) qui n'utilise jamais les fonction mysql, je n'ai pas vu une difference enorme, mais tes bench m'interresse.

[Fladnag]

j'ai tendance aussi a privilegier les fonctions mysql, meme si je les connais moins bien que celle de php, donc souvent j'ai toujours du boulot a faire en php que j'aurais pu faire en mysql ;o)

Je ne pense pas que l'on puisse répondre simplement a ta question pour le cas général. Choisir de charger le serveur php ou la base est un choix a faire au cas par cas, ca depend de l'utilisation de chacun... Si tu as deja des traitement de 20secondes en php sans acces a la base, autant charger la base, et si tu as 50 requetes mysql pour une petite page php, autant les faires en php.

A la limite le temps d'execution "pur" sur un environnement non chargé aura du sens, mais a mon avis la connexion et la charge SQL dépend de tellement de parametres dans un environnement de production qu'il sera difficile d'en déduire quelque chose...

Je dirais que c'est le meme debat au fond que l'objet vs procédural. L'objet est souvent utilisé alors qu'il est legerement plus lent (j'veux pas lancer un troll, pas taper !) mais sa facilité de (ré)utilisation lui assure un large couverture d'utilisation.
Pour moi c'est a la base d'en faire le maximum, car elle ne peux pas en faire "beaucoup" dans les traitement en général. Donc quand c'est possible je laisse la base le faire.

De plus, les problemes d'optimisations sont les problemes des bases de données depuis le commencement, je pense donc qu'ils sont plus doués dans ce domaine que PHP qui est un langage relativement jeune.

[gisele]

Salut vous 2,

effectivement j'ai aussi tendance à essayer de régler un maximum de problèmes au niveau de la requête SQL en allant systématiquement chercher des solutions les plus directes et compactes possibles au niveau des possiblités SQL (fonctions, Join, Union etc.).
De sorte qu'il me reste le moins possible à faire en PHP.

Mais tu as raison Fladnag, Il y a trop de facteurs d'une prod à une autre, deplus, les process http qui finalement bossent en synchrone avec les process SQL sont de toute façon dépendant de ses derniers.
Voila qui qui apparemment renvoie dos a dos les 2 stratégies entre charger le serveur SQL ou plus charger le serveur Web.

Perso ca aurait tendance a me conforter dans l'idée de vouloir faire faire la besogne au serveur SQL à chaque fois que c'est possible pour la simple raison que les accès au serveur SQL ne constituent qu'une (parfois petite) partie des besoins du serveur web qui supporte "tout" le reste de l'appli.
Le serveur SQL n'étant finalement qu'un sous-traitant d'une partie du travail (cela peut varier d'une appli a l'autre bien sur).

En relisant le post de Fladnag, c'est d'ailleurs comme çà que je comprends :"Pour moi c'est a la base d'en faire le maximum, car elle ne peux pas en faire "beaucoup" dans les traitement en général. Donc quand c'est possible je laisse la base le faire." que j'approuve à 100%


En ce sens, cela me semble plus être un rééquilibrage qu'un déséquilibrage vers le serveur SQL.

Cette approche généraliste sur la gestions des ressources étant faite (et pas forcément close, bienvenue a tous) je reste très curieux de mesurer les performances pures des fonctions PHP d'un coté et Mysql de l'autre.

je continue mon enquete et reste ouvert à des suggestions de protocoles expérimentaux...

[ePoX]

Moi j'ai plutot tendance à le faire en PHP...
Sauf les jointures qui pour moi ne rentre pas dans le cadre de la question intiale, puisque se sont des possibilités permettant la lecture de données et non leur transformation comme les fonctions date ect.

Si j'utilise PHP c'est juste pour exprimer clairement et lisiblement ce que je fais. SQL c'est sympa, mais bon.... Moi sa me lourde quand la requete devient inutilement compliquée.

A ceci j'ajouterais que décharger un maximum le sgbd me permet d'être plus sur de la portabilité du code.

Cependant ces fonctions sont extrement utile pour faire du tri dans les données par exemple GROUP BY MONTH(date_toto). C'est bien le genre de chose que a ne faire en PHP qu'en dernier recours.

[gisele]

Salut,

Salut tu as raison les jointures ne transforme pas les data, mais nombre de possibilités de jointures insoupçonnables permettent une rationalisation du code et évite des boucles alambiquées en PHP qui se soldent finalement par des accès intempestifs a la base.

Pareil on ne peut dénigrer la complexité des requetes des solutions SQL qui au contraire permettent souvent d'éviter des contorsions PHPesques et autres solutions souvent plus tordues.

Egalement, s'agissant d'exprimer clairement et lisilement ce que l'on fait je pense qu'une requete SQL me semble au moins aussi explicite (cela variera avec les affinités de chacun avec le SQL) que du code PHP.

C'est comme tout il ya des requets pourraves mal foutues je l'accorde mais souvent dues a la connaissances approximative des possibiltés d'un SGBD.

Je t'accorde cependant un point important, la portabilité, on peut se faciliter la vie avec des requetes imbriquées jusqu'au jour ou ou il faut porter son applicatif sur une config comportant un serveur Mysql < 4.1.

Mais ceci vaut pour tout et surtout le PHP par exemple on a pas toujours la possiblité (et le plaisir en ce qui me concerne) de faire de l'objet sophistiqué ou parser du XML en PHP5.

[ePoX]

Je ne me suis peut être pas très clairement exprimé. Mais typiquement une requete avec jointure c'est à mon sens irremplaçable. C'est la l'essence du sgbd et j'en remercie ces concepteurs tous les jours .

Par contre ceci :

Code :

1
2
3
4
$SQL = "SELECT FROM_UNIXTIME(MON_CHAMP_TIMESTAMP, 'mon formatage')  ...
[...]
while($data = mysql_fetch_row....)
   print $data[0];

A part dans des cas très très particulier je prefere de loin le faire en php.

je préfére préciser au cas ou.

[Biglo]

Salut,

Je n'ai jamais réalisé de benchmarks pour comparer les fonctions de date de MySQL et de PHP. Mais je pense que tous les deux proposent des fonctions optimisées pour ce genre de traitement.

En tout cas, le choix se fait essentiellement sur une préférence personnelle. Ton exemple de formater une date n'est peut-être pas le meilleur (si tu en as d'autres, n'hésite pas à les donner ). Personnellement, je n'ai aucune préférence à utiliser date() ou une fonction du genre FROM_UNIXTIME() / DATE_FORMAT().

Par contre, si je dois afficher la date du jour sur un site, je me vois mal faire :

Code :

SELECT DATE_FORMAT(CURDATE(), '.....')

Là, je suppose que la majorité des gens vont utiliser directement date() en PHP.

Mais si on doit afficher tous les événements qui auront lieu dans 1 semaine, je trouve quand même plus propre de le faire en SQL plutôt que de calculer en PHP la date dans 7 jours, puis de faire la requête.

En bref, je dirais qu'en ce qui me concerne : si la fonction doit être utilisée pour l'affichage sur le site, je ferais plutôt appel à PHP. Mais si c'est pour resteindre des résultats (clause WHERE) d'une requête, je le ferais directement avec MySQL.

[backeyes]

Bonsoir,

Pareil je me suis déjà posé la question mais c'était entre le COUNT de sql et le mysql_num_rows de php.
Je me suis dit que j'allais comparé les temps d'exécution etc avec beaucoup d'enregistrements un de ces jours, mais si quelqu'un l'a déjà fait ça m'intéresse

[icebreak]

Normalement, le traitement de MySQL est beaucoup plus rapide que celui fait par PHP. Donc toujours privilégiez le traitement MySQL sur celui de PHP.

[Fladnag]

Envoyé par backeyes

Pareil je me suis déjà posé la question mais c'était entre le COUNT de sql et le mysql_num_rows de php.
Je me suis dit que j'allais comparé les temps d'exécution etc avec beaucoup d'enregistrements un de ces jours, mais si quelqu'un l'a déjà fait ça m'intéresse

Je ne l'ai pas testé, mais je sais que le SELECT count(*) FROM table WHERE ... est spécifiquement optimisé dans mysql, donc a privilegier dans tout les cas. Maintenant, si tu as besoin de recuperer des données (donc de faire une requete SELECT ... derriere), il est evident qu'il vaut mieux faire une seule requete avec un mysql_num_rows que 2 requetes avec un count(*) d'abord.