Régulièrement, je reprends un peu de théorie php / sql histoire d'approfondir ou de ne pas tout oublier en tout cas
Là, je vois que depuis la dernière fois, le tuto officiel du site dédié au php, a fait le switch vers l'extension PDO et non plus mysql_ ...
Tout le monde est "d'accord" sur l'intérêt de ce changement ?_?
Je me pose une série de questions... J'ai bien compris l'intérêt que PDO a (cf. compatible avec SQL, postgre, etc), mais on a autant de possibilités ? (davantage peut être même... ?) Y a aussi de la doc "facile" qui reprend un peu toutes les requêtes existantes (à moins qu'il y en ait assez peu en fait, et que le tuto en fasse le tour ?)
En d'autres termes, ceux parmi vous qui avaient commencé avec mysql_ sont passés à PDO ? (et nooooon chuis pas paresseux ! )
Evidemment qu'il faut changer. Que tu utilises l'un ou l'autre, ça ne change strictement rien pour tes requêtes. Le langage SQL lui ne change pas (un petit peu quand même mais les différences se situe entre les SGBD pas les API php)
Donc oui, mets-toi à jour. Pour la simple et bonne raison que l'API mysql est voué à disparaître avec PHP6.
En effet PDO est plus intéressant. Quitte à l'utiliser je te conseillerai d'étendre la classe PDO, pour la transformer en singleton, et éventuellement ajouter tes propres fonctions qui te renverront sous la forme voulue tes données.
Personnellement j'aime bien avoir une fonction pour quand je retourne un champ, une pour une ligne, et une pour plusieurs lignes. Ce qui permet de savoir instantanément ce que tu vas récupérer.
PDO est orienté objet (ce qui va dans le sens de l'évolution de PHP), PDO permet plus de possibilité :
Possibilité d'avoir des requêtes préparées qui sont utiles pour les requêtes lancées plusieurs fois avec des paramètres différents.
Ces fonctions préparées préviennent les injections SQL.
Plus besoin de passer par une boucle while pour les requêtes à lignes multiples, un fetchAll() et on en parle plus.
Et il y a surement encore des avantages que je ne connais pas forcément.
Pour la sécurité utilise plutôt la fonction quote que les requêtes préparées. Les requêtes préparées ont leur raison d'être, mais leur vocation n'est pas d'assurer la sécurité contre les injections sql.
C'est assez répandu comme utilisation, mais cela gaspille des ressources serveurs. Ne préparez une requête que si vous allez l'utiliser plusieurs fois sur la même page.
Evidemment qu'il faut changer. Que tu utilises l'un ou l'autre, ça ne change strictement rien pour tes requêtes. Le langage SQL lui ne change pas (un petit peu quand même mais les différences se situe entre les SGBD pas les API php)
Donc oui, mets-toi à jour. Pour la simple et bonne raison que l'API mysql est voué à disparaître avec PHP6.
Bonjour,
Il va s'en dire que PHP6 à été mis au placard pour le moment. D'aprés ce que j'ai pu en lire. Cette futur version de PHP(java like) serait trés dur à réalisé.
Les concepteur de PHP on aujourd'hui un mal fou à faire évolué le noyau tellement il serait mal organisé. Une refonte du core de ce language permettrait d'amélioré c'est performance est cette voie pourrait être favorisé si les difficultés à le faire évolué ce multiplie.
Cependant, muse_stream passe à la PDO si ton hebergeur le permet.
Le mieux c'est encore d'utiliser une couche DAL (type Zend_Db, créole, etc...) pour éviter de programmer trop bas niveau, car dans le fond mysql[i]_* ou PDO au niveau de l'application on s'en fiche , le but étant d'avoir des objets pratiques pour accéder la base et dans les deux cas c'est possible.
+1 xrorox: depuis plusieurs semaines les posts s'enchainent ici pour inciter à l'utilisation des requêtes préparées. C'est une ânerie, trois accès internes au serveur (PREPARE / SET @xxx / EXECUTE) pour exécuter un truc qui dans 99.9% des cas ne sera utilisé qu'une seule et unique fois (à moins de faire des requêtes dans des boucles ^^) c'est une perte de temps et de ressource sèche. Pour rappel la préparation d'un ordre est associée à la session (connexion mysql) donc aucune mutualisation du plan d'exécution des requêtes entre les utilisateurs.
Conclusion dans tous les cas si vous ne souhaitez pas utiliser de couche d'accès aux données (Data Access Layer), et quel que soit l'API choisie (mysql[i]_*, PDO) vous serez amenés à développer des moyens pour échapper automatiquement les arguments SQL en conservant pour simplifier la syntaxe avec les ? ou les :nom
+1 xrorox: depuis plusieurs semaines les posts s'enchainent ici pour inciter à l'utilisation des requêtes préparées. C'est une ânerie, trois accès internes au serveur (PREPARE / SET @xxx / EXECUTE) pour exécuter un truc qui dans 99.9% des cas ne sera utilisé qu'une seule et unique fois (à moins de faire des requêtes dans des boucles ^^) c'est une perte de temps et de ressource sèche. Pour rappel la préparation d'un ordre est associée à la session (connexion mysql) donc aucune mutualisation du plan d'exécution des requêtes entre les utilisateurs.
T.
2 questions concernant cette histoire des requêtes préparées :
- en clair, si j'ai une requête à faire : je sécurise ma variable que je soumet direct au ->query ?
- en clair, j'ai pas compris quand c'est utile d'utiliser les préparées cf. ton histoire de boucle mais où est-ce qu'on y gagne ???
Niveau performance si tu fais des benchmark un peu poussé, je préfère l'interface objet mysqli ( new mysqli([OPTIONS]); ), tu as de meilleurs résultats.
je n'utilise PDO que si je dois faire un traitement multi SGBD...
Elmsroth - Ingénieur informatique - Web & Logiciel
Elle l'est déjà plus ou moins. Un coup d'œil dans la doc nous dit ça :
Citation : Doc
Although this MySQL extension is compatible with MySQL 4.1.0 and greater, it doesn't support the extra functionality that these versions provide. For that, use the MySQLi extension.
Alors qu'on en est à la 5.5... Donc après, peu importe ce que tu utilises, mais si tu veux profiter pleinement des dernières fonctionnalités, n'utilise pas l'API MySQL.
- en clair, si j'ai une requête à faire : je sécurise ma variable que je soumet direct au ->query ?
oui, tu échappes (enlève sécurise de ton cerveau le but n'est pas là) avec pdo::quote().
Citation : muse_stream
- en clair, j'ai pas compris quand c'est utile d'utiliser les préparées cf. ton histoire de boucle mais où est-ce qu'on y gagne ???
Ben quand le même ordre doit être posté plusieurs fois dans le même traitement (même requête http pour le web), éventuellement avec des valeurs différentes. Cas d'utilisation super rare.
@vyk12: a part les problèmes concernant l'invocation des procédures stockées depuis mysql_* quelles sont les autres extra-fonctionnalités ?
Je serai tenté de dire si vous voulez gagner du temps d'utiliser des procédures sql. Je ne saurais affirmé que c'est vraiment plus rapide.
Personnellement, j'aurais tendance à penser que oui. Enfin, ca dépends de ton site, et de la charge de ton serveur sql, si tu en as un séparé. Et bien évidemment de l'utilisation que tu en fait.
Encapsuler une requête update par exemple dans une procédure, je ne suis pas sûr qu'on obtienne des gains substantiels. Bien qu'on fasse tomber la charge réseau.
Par contre dans le cas de traitements de ce style : Sélection SQL.
Modification des données sans qu'on s'en serve côté php.
Réinsertion ou update dans la base, on peut obtenir des gains importants.
Puisque je parles d'optimisations. J'ai déjà parlé de singletons et autres. Mais vous gagnerez à faire vos traitements sous la forme :
==> Ouverture connection.
===> Toutes les requêtes sql que vous voulez.
==> fermeture connection
==> traitement.
J'ai parlé d'une classe PDO2, implantant un singleton. Le lien suivant est celui d'un code fait par un utilisateur du site du zéro. ici Ce code là dispose juste du singleton. Si vous souhaitez le rendre plus utile, vous pouvez modifier le code pour récupérer une instance de PDO2. Et ajoutez vos propres méthodes de traitement.
Par exemple, j'aime bien avoir une méthode $connexion->loadSqlResult($sql), quand je ne veux récupérer qu'un champs. De plus vous pouvez mettre tous vos traitements dans ces méthodes, clarifiant ainsi votre code.
loadSqlResultArray pour une ligne par exemple.
loadSqlResultArrayList pour plusieurs.
loadSqlExecute pour tous les insert, update, delete.
Personnelement, en php je ne fetch pas en objet, mais c'est tout à fait possible de le faire.
Un de ces jours, il faudra que j'envisage de faire un tuto sur des bonnes techniques de programmation. Quoique y en faudrait un de manière générale, et un spécialisé pour chaque langage. Je suis en train de lire un bouquin passionant sur le sujet sur RoR .
En fait les 2 sons utilisables en français. Du moins à ma dernière vérification sur un dictionnaire en ligne. Mais je n'ai pas pris l'avis de l'académie française.
<citation rid="6473240">
@vyk12: a part les problèmes concernant l'invocation des procédures stockées depuis mysql_* quelles sont les autres extra-fonctionnalités ?
En gros, tout ce qui est apporté par MySQL 4.1+. Genre les transactions par exemple. En fait, ce qui est dit sans être dit : mysql_* est déprécié. mysqli_*, non. Mais il est recommandé de passer par PDO (et bien évidemment encouragé à utiliser Doctrine, Zend_DB, ou autres).
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Keep It Simple Stupid - SF4 conf Swift - Cours 1/4 SF4 - Exceptions PDO - Formes Normales
Keep It Simple Stupid - SF4 conf Swift - Cours 1/4 SF4 - Exceptions PDO - Formes Normales
Keep It Simple Stupid - SF4 conf Swift - Cours 1/4 SF4 - Exceptions PDO - Formes Normales