salut,
et marche aussi et evite les concatenations
++
Code : Sélectionner tout - Visualiser dans une fenêtre à part echo '<table>' ,' <tr>' ,' <td>' ,$var,'une concaténation de chaînes...';
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
salut,
et marche aussi et evite les concatenations
++
Code : Sélectionner tout - Visualiser dans une fenêtre à part echo '<table>' ,' <tr>' ,' <td>' ,$var,'une concaténation de chaînes...';
Si on écrit en ligne y'a plus aucun intérêt à faire des concaténation, autant faire directement echo '<table><tr>...';Envoyé par _Gabriel_
Parfois on présente sur plusieurs lignes pour s'y retrouver dans le code PHP.
Salut
vous êtes au courant que :
echo '<table>
<tr>
<td>Contenu du td</td>
</tr>
</table>';
marche aussi trés bien et à mon avis est bien plus lisible que votre concaténation de chaîne innutile à moins qu'une variable n'intervienne dans le chmilblique ...
Another
Toujours avec MySQL ( de toutes facons, les vraies optimisations ( celles qui font gagner plus que quelques dixièmes de miscroseconde ) ne touchent principalement que les accès BDD).
Il arrive fréquement lors d'un SELECT, notemment lorsqu'un spécifie un WHERE ou équivalent dans la requête, que l'on sache a 100% que le retour de la requete ne comportera qu'un seul enregistrement.
Déja, la première bonne idée c'est de ne pas faire de boucle, on peut y aller directement comme ceci :
Ensuite, si l'on est toujours dans la meme configuration et que en plus, on nomme les champs que l'on va selectionner dans la requete, au lieu de faire comme ci dessus et d'ensuite utiliser le tableau '$results', on peut utiliser une fonction assez méconue : list(), comme ceci:
Code : Sélectionner tout - Visualiser dans une fenêtre à part $results = mysql_fetch_array(mysql_query("SELECT * FROM table WHERE champ = 'valeur'"));
On peut ainsi utiliser directement les variables, en plus on utilise un mysql_fetch_row au lieu d'un
Code : Sélectionner tout - Visualiser dans une fenêtre à part list($var1, $var2, $varn) = mysql_fetch_row(mysql_query("SELECT champ1, champ2, champn FROM table WHERE champx = 'valeur'"));
mysql_fetch_array.
Les malins auront compris que dans le cas ou les retours de requetes sont multiples, on peut utiliser list() sur le tableau analysé par la boucle pour des raisons pratiques.
Re: Another
salut
la je suis pas tout a fait d'accord avec toi; je pense qu'il faut -meme si tu t'attends theoriquement a n'avoir qu'un seul enregistrement - a tester le nombre d'enregistrements que tu as recuperé: on ne sait jamais, si un petit malin voulait faire du SQL injection...
je suis d'accord, il faut vérifier...
Je suis un peu mort de rire, il m'arrive très souvent que je sache très bien que je vais n'avoir qu'un seul retour, j'en suis sur a 100% et nimporte quel petit malin ne pourrait rien y faire.
Exemple pour les sceptique :
Dans une table avec un champ 'id' déclaré en auto_increment et clef primaire (cad 99% de mes tables) .
Bah je t'assure que je n'aurai qu'un seul retour.
Code : Sélectionner tout - Visualiser dans une fenêtre à part mysql_query("SELECT champ1, champ2, champn FROM table WHERE id = '2'");
Mais vous pouvez toujours ne pas me croire et tester le nombre de retour ou faire une boucle.
Edit : c'était un exemple
on est bien d'accord dans ce cas la
par contre, point de vue optimisation, ta requete est pas terrible...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
En parlant des SELECT *, si on a qu'un ou deux champs de l'enregistrement à récupérer, il vaut mieux les spécifier :
Mais si on a réeellement besoin de tous les champs, c'est quoi le plus rapide?
Code : Sélectionner tout - Visualiser dans une fenêtre à part SELECT nom, email FROM...
Et puis quand un select renvoie plusieurs enregistrement, vous faîtes comment pour y accéder les uns la suite des autres?
ou avec each?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Je pense que la dessus on doit pouvoir gagner plein de temps sur des requetes avec plein d'enregistrements.
Une très bonne optimisation niveau quantité de donnée est l'utilisation des méthodes __sleep() et __wakeup() quand on veut sauvegarder un objet serialisé (je connais pas le mot en français).
Si par exemple j'ai un objet voiture, ily a des caractéristiques qui ne changent pas la marque, la puissance, le nombre de pneus... Dans la fonction __sleep() je précise que je ne souhaite garder que les attributs variables (kilométrage, jauge d'huile, d'essence,...) ainsi que le type de voiture. Et ensuite dans la fonction __wakeup(), je vais charger à partir de la base de donnée les informations fixe (marque, puissance,....) qui correspondent au type de voiture.
Ainsi, l'objet serializé prend bcp moins de place.
j'ai pas tout compris là ton sleep et wakeup mais si c'est pour faire des requêtes à la base pour retrouver des infos... ouais... :-/
C'est pour le cas où on voudrais sauvegarder un objet php tel quel, dans une session, un fichier ou une base de donnée. Pour ce faire on est obligé de transformer l'objet en chaîne de caractère via la fonction serialize (la fonction est automatiquement appelée quand on sauvegarde dans une session).
Cette chaîne de caractère contiendra toutes les données de l'objet (mais pas les méthodes), le problème est que pour un gros objet ça prend de la place, d'où l'intérêt des méthodes __sleep() (pour alléger l'objet) et __wakeup() (pour récupérer les informations non enregistrée).
Désolé si j'ai pas été très clair. Je vous fais par de cette optimisation car elle m'a été très utile récemment pour diminuer le poids d'objets que je souhaitais sauvegarder en base de données.
ah ok yé comprend mieux
même si les objets et les sessions en php c'est pas mon point fort
ben d'un coté tes objets sérialisés prennent moins de place mais de l'autre, tu es obligé de refaire des requetes pour compléter les infos fixes que tu as retiré lors de la sérialisation.
Les requetes SQL entraînent un ralentissement.
Donc entre place occupée et performances, il faut choisir.
Pour ma part je charge toutes les données "fixes" (dans cet exemple ce serait toutes les données sur les type de voitures) lors du login et je les garde en session. Ainsi quand j'ai besoin de charger un objet "voiture", je n'ai que les données variables à charger à partir de la bdd le reste je le charge à partir des données gardées en session.
Plus besoin de faire une grosse requête pour récupérer toutes les données invariables. C'est donc à la fois optimisé en temps (un seul chargement) et en poids (l'objet voiture est bcp moins lourd).
Le seul inconvénient est que ce n'est pas forcément adapté à ts les problèmes. Etant donnée que mon objet voiture est sérialisé, je ne pourrais jamais faire de requête pour en extraire des données ou faire des stats. Mais ça peut servir dans certain cas.
A noter que dans cet exemple, il est préférable d'enregistrer les données dans la base de données "champs par champs" (cad un champs pour chaque attributs) et non un seul champ contenant l'objet sérialisé. Mais par contre ça peut s'avérer très pratique dès qu'on doit manipuler des objets contenant des listes d'autre objets.
Ca évite de créer un table intermédiaire contenant les liens entre les objets, ce qui peut pas mal ralentir le script quand il y a beaucoup d'objet avec de grandes listes.
Imaginon un objet 'personne' possédant une liste d'objet 'meubles'.
5 000 personnes sont stockées, chacune possédant dizaine de meubles en moyenne. Et bien dans la table de lien ça fera 50 000 liens personne<->meuble et les requête de sélection pour trouver quels meubles appartiennent à quels personnes seront d'autant plus longues.
Par contre si on utilise des objet serialisés et bien il suffit de rajouter un champ 'liste_meubles' dans la table personne, contenant la liste des meubles sous forme d'objet sérialisé (une champ texte suffit). Et là, plus besoin de faire de jointure sur une table gigantesque. Cependant on ne pourra plus faire de statistique directement par une requête ou encore faire la requête inverse, cad récupérer la liste des personnes possédant un meuble donné.
C'est comme toute structure de données, ça a ses avantages et ses inconvénient, il faut voir en fonction de ses besoins...
intéressant ce que tu dis là !
Ok j'avais pas vu ca comme ca mais ca peut etre intéressant
Re: Another
Oui mais il n'y a quasiment aucune différence. Le manuel le rapelle bien, la fonction mysql_fetch_array est aussi rapide que mysql_fetch_row (mtsql_fetch_row est un cas particulier de mysql_fetch_array avec result_type à MYSQL_NUM).
Pendant mes longues heures sans internet, j'ai créé un bench
http://iubito.developpez.com/php/bench.php
Au programme :
- Guillemets et apostrophes dans les chaînes
- while (list($key,$value) = each($array)) ou foreach ?
- $array['key'] - $array[key]
- str_replace : plusieurs appels ou avec des tableaux ?
- Application 1 : enlever les accents
- file_exists ou is_file ?
et possibilité de voir la source du bench.php, faites un copier/coller et testez sur votre ordi pour voir si les résultats correspondent aux miens. Vous aurez pas forcément la même vitesse de calcul, mais vous devez normalement arriver aux même conclusions que moi ("untel + rapide que l'autre"...)
Perso ma config est un AMD XP2400+ avec 1Go de RAM donc ça trace pas trop mal
Youpi! C'est vraiment génial ^^
Beaucoup de choses étaient prévisibles mais ton bench permet de voir dans quelle mesure cela influence sur les performances.
Je me posais aussi des questions sur le foreach ou while et bien la j'ai la réponse
merci!
Répondre avec citation
Partager