Comprendre PDO [Article]

[FMaz]

Bonjour à tous.

Je viens de compléter un article portant sur ... PDO !
Bien qu'il existe plusieurs articles du genre, je trouvais que la plupart expliquaient d'avantage comment utiliser PDO, mais rarement le pourquoi des choses. Ainsi, j'ai essayé de créer un article qui va au fond des choses en me remémorant tout ce que j'ai pus trouver complexe à saisir par moi-même au début.

J'ai aussi tenté de cibler les principales incompréhensions que j'ai constaté sur le forum, et d'étayer des réponses les plus simples possible. Il s'agit donc d'un article de niveau débutant/intermédiaire.


Pré-requis à la lecture:
- Une base en PHP
- Une base avec les fonctions mysql_ ou mysqli_
- Un peu de temps

Voici donc l'article en question:
http://fmaz.developpez.com/tutoriels...omprendre-pdo/


Vos commentaires seront les bienvenu !

[sabotage]

Une petite coquille : "l'extension MySQL a fait son temps. "

Sinon ce genre d'articles est nécessaire car on voit bien sur le forum que mysql_ qui est le pire choix des trois reste largement utilisé.

[FMaz]

Merci pour la coquille, c'est déjà corrigé

Et ouais, c'est aussi ce que je me disais... En fait j'ai constaté que beaucoup de gens ne comprennent même pas ce qu'est une requête préparée, et qu'ils pensent que c'est une particularité de PDO...

Et que d'autre pense que les requêtes préparés sont "l'unique" facon de faire une requête avec PDO: et que c'est beaucoup plus long qu'un mysql_query().

Alors voilà, je voulais abattre ces quelques préjugés trop souvent mal expliqués.

[pc.bertineau]

Bonjour,

J'utilise PDO depuis longtemps et je trouve votre article bien rédigé, en expliquant bien ce qu'est et ce que n'est pas PDO...

J'ai une question à propos :

Pour des insertions massives en base, j'utilise le plus souvent les requêtes préparées sans les fonctions "bind" mais en passant directement un tableau de valeurs à la requête préparée :

Code :

1
2
3
4
5
$prep = $db->prepare('INSERT INTO table (champ1, champ2, ..., champN) VALUES (:champ1, :champ2, ..., :champN);');
 
$values = array(':champ1' => $value1, ':champ2' => $value2, ..., ':champN' => $valueN);
 
$prep->execute->($values);

Je me suis auparavant assurer du bon type des valeurs passées en paramètre. Mais je me demande si cette utilisation protège des injections SQL ?

[Doksuri]

bon petit article..simple et clair
moi qui me mettais doucement a PDO... je vais abandonner les autres maintenant xD

[RunCodePhp]

Salut

Je lis actuellement avec beaucoup d'attention cet article.
Excellent travail, faut le dire.

J'en ai donc même terminé que je me suis empressé d'essayer cette ligne :

Code :

$arrExtraParam= array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8");

Et là j'obtiens une erreur comme quoi la constante de classe MYSQL_ATTR_INIT_COMMAND n'existe pas.

J'ai beau éplucher toutes les constantes PDO au niveau de la Doc, je ne la vois pas effectivement, et rien permettant de la remplacer.
Je vois quand même celle ci : MYSQLI_INIT_COMMAND, donc pour MySQLi.
Malgré tout, ce n'est pas une constante de classe de PDO.

As tu eu cette erreur ?
Personnellement je n'est pas d'idée du comment exploiter cette technique, actuellement j'effectue un PDO::exec('SET NAMES utf8').

[FMaz]

J'en ai donc même terminé que je me suis empressé d'essayer cette ligne :

Code :

Et là j'obtiens une erreur comme quoi la constante de classe MYSQL_ATTR_INIT_COMMAND n'existe pas.

Bon alors oui la constante existe bien, voir: http://php.net/manual/fr/ref.pdo-mysql.php

Note au passage concernant le fait que PHP exige des valeur entière: comme valeur, on peut mettre "SET NAMES utf8" ou l'entier 1002, ca reviend au même.

Sinon tu peux simplement faire ceci:
$db->query("SET NAMES 'utf8'");

Edit: Sinon je recherche un peu, je crois avoir lu qu'il y avait un bug avec PHP 5.3 quelque part.
Edit2: Ah voilà le bug en question: http://bugs.php.net/bug.php?id=47224 . En bref: c'est un bug dans php 5.3.0, et c'est corrigé dans la version 5.3.1.


---------------

Pour des insertions massives en base, j'utilise le plus souvent les requêtes préparées sans les fonctions "bind" mais en passant directement un tableau de valeurs à la requête préparée :

Code :

Hum, je suis un peu hésitant. La pratique est tout à fait légitime, et il n'y a rien de mal à ne pas utiliser les méthodes de binding. Cependant, pour être honnête, je ne sais pas trop.

Mais si tu ne mentionne rien, je crois (à valider) que par défaut la protection devrait être de type STRING pour toutes tes valeurs... (Tu pourrais essayer de reproduire le faux-bug du limit pour voir si c'est bien le cas)

De plus, j'aimerais faire une mise en garde que l'utilisation des requêtes préparée n'est pas une protection absolue contre les injections. Vous devez tout de même valider vos entrés. (Donc si tu les a bien validée comme tu le dis, il ne devrait pas y avoir de problème).

[stealth35]

le bind ca sert surtout avec FETCH_BOUND.

[RunCodePhp]

Note au passage concernant le fait que PHP exige des valeur entière: comme valeur, on peut mettre "SET NAMES utf8" ou l'entier 1002, ca reviend au même.

Oui, je m'en suis douté que cette constante retournerait un entier, mais vu quelle n'existe pas de mon coté (bug, surement), je ne voyait pas quelle valeur.

J'ai remplacé comme ceci :

Code :

1
2
 
$arrExtraParam = array(1002 => 'SET NAMES utf8');

Il n'y a certes plus d'erreur, mais je ne suis pas en UTF-8 pour autant.

Bon, si tu as une idée, tant mieux, sinon je chercherais un peu plus longuement un autre jour.
Pour le moment ce n'est franchement pas important, c'était plus par curiosité.

Merci et excellent article encore une fois.

[gene69]

bonjour

quatres observations:

• les remerciements dans le texte, c'est pénible à lire, à la fin, c'est bien.
• un argument plus détaillé sur la gestion des exceptions par PDO aurait flatté le lecteur curieux et non pratiquant que je suis, parce qu'à l'heure actuelle, une surcouche maison peut très bien s'occuper de protéger les données de façon aussi efficace. à part alléger la syntaxe...
• pourquoi PDO si mysqli est plus performante aujourd'hui? J'en ai rien a faire d'une extension qui fonctionnera bien dans 5 ans pour mes développements d'aujourd'hui.
• comment obtenir une trace sql avec PDO? ça fait parti des préalables sur lequel je ne suis pas prêt à transiger. J'ai besoin d'une trace sql au niveau applicatif, mes bases ne voient généralement qu'un seul utilisateur, or il y en a plein dans la vraie vie. or jusqu'à présent, la classe d'accès aux données est un terrain stratégique pour espionner l'utilisateur.

l'article est clair et c'est un bon travail, merci.

[hornetbzz]

Bravo, vraiment très bien, complet, très facile à lire et à comprendre, même pour un noob comme moi.

L'intérêt de PDO est expliqué objectivement, ça laisse le choix au lecteur en connaissance de cause.

La "passerelle" avec mysql est bien expliquée et les comparatifs sont explicites, ce qui peut aider à franchir le pas.


J'ai juste 2 petites remarques :

1) Remarque perso: ça aurait été bien de parler un minimum des singletons, me semble-t-il. En tous cas en ce qui me concerne, pour avoir bien galérer avec ce sujet il y a qq temps. Mais ça n'intéresse peut être pas tout le monde.

2) Chapitre III.d. Réutiliser une requête préparée pour gagner en performance. Un petit benchmark de perf (PDO/MYSQL) aurait été sympa.

Et encore merci, ce tuto manquait au palmarès

[FMaz]

Il faut savoir que l'article pourra être améliorer, je note donc vos suggestions. ( En fait pas vraiment, ce serait mieux si vous n'effaciez pas vos réponses :p )

hornetbzz:

Parler des singletons: Pour quel usage exactement ? Le seul singleton qui me semble raisonnable d'adopter sans tomber dans la singletonnite aigue serait pour faire un connexion manager, mais c'est un peu hors du cadre de cet article (mais peut-être pas d'un second volet)

Benchmark: Ouep, je vais y voir


gene69:

Trop de remerciements: Il n'y en a pas tant que ca ? As part pour Guillaume, je vois pas trop quel remerciement j'ai fait dans l'article.

Gestion des exceptions: C'est hors du cadre de l'article, mais ca pourrait très bien se joindre à un second volet en même temps que de parler d'un connexion manager qui étend les classes PDO. Cet article s'adresse à l'explication de la base. Il se veux donc clair, pertinent pour une majorité des ca, et surtout direct et concis.

C'est donc un choix volontaire de ne pas en avoir fait un tutoriel "de réalisation" ou un guide sur les pratiques de développement. À la limite, certaines personnes peuvent ne pas vouloir utiliser les exceptions dutout, tout comme j'ai démontré que les requête préparée n'était pas obligatoires...

Pourquoi PDO si mysqli est plus "performant": J'aimerais quelques bench à ce sujet, mais sur la base, j'aurais tendance à répondre simplement: Pourquoi C++ si l'assembleur est plus performant ? Pourquoi Java si C++ est plus performant ?

Si MySQLi fait bien le travail pour les applications actuelles: tant mieux. Mais le futur de PHP se dirige clairement vers PDO, vaux donc mieux s'y mettre Par exemple, Doctrine est une sur-couche de PDO. Donc pour ceux qui souhaitent utiliser un ORM dans un projet, ca deviens essentiel.

comment obtenir une trace sql avec PDO? Tu peux me préciser ce que tu recherche concrètement ? (Pour moi une trace est une liste du chemin d'exécution ayant mené au point du "bug". XDebug permet d'avoir une trace de son code PHP. Mais dans le cas d'une requête, je vois mal la pertinence d'avoir une trace; il n'y a qu'une requête, puisque chaque requête est isolée...)

[FMaz]

Envoyé par RunCodePhp

J'ai remplacé comme ceci :

Code :

Il n'y a certes plus d'erreur, mais je ne suis pas en UTF-8 pour autant.

Je crois qu'avec PHP 5.3.0, c'est sans espoir.
As-tu essayé ceci ?

Code :

1
2
 
$db->query("SET NAMES 'utf8'");

?

[hornetbzz]

Singleton:

Je pensais en réalité à cet article vers lequel tu pourrais peut-être faire un renvoi du genre "aller plus loin".

En fait ça m'intéresse à titre perso, car lors de ma phase "découverte" de la POO et PDO, j'étais tombé sur un bug PDO- un peu par hasard - qui m'avait été mis en évidence par Runcode, PetitBidon et AcoeurPerdu. Ce bug était apparu justement en cherchant maladroitement à coder un singleton.

[grunk]

pourquoi PDO si mysqli est plus performante aujourd'hui? J'en ai rien a faire d'une extension qui fonctionnera bien dans 5 ans pour mes développements d'aujourd'hui

J'aurais aussi et surtout envie de dire qu'avec PDo tu as un interface uniformisée. Effectivement si tu ne travail qu'avec des bases mysql l'intérêt est moindre , mais par exemple j'ai plusieurs projet qui fonctionnent avec une base local et une base distante qui ne sont pas les même (sqlite/mysql , mysql/mssql ...)
Avec PDO pas besoin de me souvenir des api sqlite_,mysql_ et mssql_ , je change juste mon constructeur et la suite est identique.

[jpvincent]

merci pour cet article, je n'avais encore jamais remarqué à quel point les fonctions mysql_* étaient en phase d'abandon, mais il faut dire que je n'ai pas eu de projet avec mysql/PHP depuis longtemps

sur mon dernier projet je travaille avec oracle et pour faire ma classe de connexion à la base, je me suis passé de l'abstraction faite par Zend_Framework pour directement utiliser les fonction oci_*
J'ai pu gagner en rapidité et ça m'a surtout permis d'identifier un bug de la version d'oci que PHP utilisait

en fait au début j'étais enthousiaste à propos de PDO pour abstraire la technologie utilisée pour la base, mais en même temps je n'ai jamais compris 2 choses :
- y a t il seulement des projets qui changent de base de données ?
- lorsque l'on change de base, la majorité des problèmes vient des requêtes qui ne sont plus toutes compatibles avec le nouveau moteur, et PDO n'y change rien.

ce qui m'amène à cette question à laquelle ton article ne répond pas : est ce que cela vaut le coup de (légèrement) ralentir tous les accès à la base, voir dans mon expérience de ramer pour trouver un bug, en prévision d'un changement de base de données qui n'arrivera au pire jamais, ou qui au mieux demandera énormément d'effort sur l'ensemble de tout le projet ?

[RunCodePhp]

Je crois qu'avec PHP 5.3.0, c'est sans espoir.
As-tu essayé ceci ?

C'est ainsi que j'ai fais depuis que j'utilise PDO, le problème n'est pas là.

C'est juste par pure curiosité que j'ai remarqué ce détail dans ton article, soit permettre de rajouter le charset directement en paramètre dans l'instanciation, chose que je ne savais pas, et me disant que ça va me permettre d'économiser 1 requête.
C'est dire que c'est franchement pas important.

Je te rejoins en tout cas sur le fait que ce serait peine perdue pour Php5.3.0, il y a un bug à ce niveau, je suis tombé sur rapport, et il a dû être corrigé/fixé dans les versions future.
Une affaire réglée, pas d'bol, il a fallut que ça soit un bug on va dire.

Merci d'avoir pris le temps de répondre en tout cas.




Pour donné un peu un avis par rapport à quelque remarques qui ont été faites, je trouve qu'il aurait été tout de même intéressant de parler des Exceptions pour PDO, ceci pour plusieurs raisons.

- La 1ère, c'est que les Exceptions fait partie prenante de PDO, il y a une classe dédiée PDOException, au même titre que la classe PDO elle même et PDOStatement.
Ca ne me semble pas un détail.

- Ensuite, cet article se veut, faire quelque part l'éloge de PDO (disons c'est mon impression), donc d'inciter les codeurs à utiliser PDO plutôt que les fonctions mysql_* (je résume).

- La gestions des Exceptions est à mon sens un bon argument pour ne serait-ce démontrer que PDO offre bel et bien d'autres possibilités, encore une de plus on va dire, voir une autre approche différente.
Ca sera peut être une occasion aux codeurs amateurs (car je suppose que c'est en majorité les codeurs amateurs qui n'osent pas utiliser PDO) à se frotter aux Exceptions.
Disons que même si ce n'est pas obligatoire, on se donnera la possibilité de le faire plus tard, et ça plus facilement vu que la gestion des Exceptions est déjà présente nativement.

- Le petit hic, on va dire que les Exceptions n'est pas si simple, je doute que ce soit un mécanisme si évidant que ça à comprendre.
Quelques exemples concret serait réellement un plus.
Ok, je comprends cependant que cela va à l'encontre d'un article qui se veut simple, direct et concis.
Peut alors rajouter quelques liens vers d'autres articles qui implémenterais ça.


Pour ce qui est du choix du singleton, je ne suis pas certain qu'il faille en parler.
Le modèle singleton, c'est du design patern, ça n'a pas de rapport avec PDO à mon sens, c'est de la POO, en parler ça pourrait laisser sous entendre que PDO devra être implémenter comme singleton.
Mais bon, rien n'empêche de mette un lien vers des solutions concrètes sur l'usage de PDO.


Un autre aspect, peut être l'as tu remarqué.
Bon, on peu peut être considérer ça comme n'étant pas lié à PDO, mais plutôt à MySQL, ou à l'API.
N'empêche que je trouve toujours aussi déroutant (mais vraiment) un tel comportant.

Je m'explique, et c'est très simple.
J'ai remarqué que le type de donnée que retourne un fetch() ou fechAll() n'est pas du tout respecté, que toutes les données sont considérées comme des chaines de caractères, des string.

Si on ajoute un gettype() sur chaque donnée retournée, c'est des string.
Pourtant, lorsque j'affiche les infos que retourne PDOStatement:getColumnMeta(N° colonne), ce tableau contient entre autre un pdo_type, donc le type de donnée du champ.
Si c'est un INT par exemple c'est 2 qui est retourné qui correspond à PDO..PARAM_INT.
Mais pourquoi donc PDO ne cast t-il pas cette fichue donnée ?

Bon, on va me dire que ce n'est peut être pas son rôle, et que ce serait à soit même de s'appuyer sur ce fameux type ou autre pour le faire.
Ma façon de voir reste malgré tout l'inverse, que ce serait justement à PDO de caster ces valeurs selon le type de données, ou alors, que ce soit en option, dans le même esprit que de déclarer si on souhaite une gestion des Exception ou pas.
Je me trompe peu être, ce serait une mauvaise approche, mais le fait est là.

Voilà un aspect qui de mon coté demeure toujours flou, incompris.
Que les choses soient clair aussi, je ne cherche pas de solution, ce serait m'éloigner du sujet, on va dire qu'à l'heure actuelle j'admets que c'est ainsi, je fais avec, mais que cet aspect pourrait faire l'objet d'un court passage sur les types de données avec PDO.
Voilà, voilà ...

[grunk]

- y a t il seulement des projets qui changent de base de données ?

N'importe quel CMS à l'heure actuelle est compatible au minimum mysql/pgsql ce qu ifait déjà deux bases et justifie l'utilisation de pdo ou de tout autres couche d'abstraction.

- lorsque l'on change de base, la majorité des problèmes vient des requêtes qui ne sont plus toutes compatibles avec le nouveau moteur, et PDO n'y change rien.

Si tu écris du SQL standard y'a peut ou pas de chose à revoir.

[FMaz]

La gestions des Exceptions est à mon sens un bon argument pour ne serait-ce démontrer que PDO offre bel et bien d'autres possibilités, encore une de plus on va dire, voir une autre approche différente.
Ca sera peut être une occasion aux codeurs amateurs (car je suppose que c'est en majorité les codeurs amateurs qui n'osent pas utiliser PDO) à se frotter aux Exceptions.
Disons que même si ce n'est pas obligatoire, on se donnera la possibilité de le faire plus tard, et ça plus facilement vu que la gestion des Exceptions est déjà présente nativement.

- Le petit hic, on va dire que les Exceptions n'est pas si simple, je doute que ce soit un mécanisme si évidant que ça à comprendre.

Hum-hum...
Je n'avais pas vu la chose sous cet angle...
Mais c'est vrai qu'il y a un manque à combler à ce niveau.

Qui sait, si j'ai du temps libre ( ) ca pourrait être un second article.

[stealth35]

y'a toujours le mode PDO::ERRMODE_WARNING, t'as mis le PDO::ERRMODE_EXCEPTION par défaut mais tu fais aucun try...catch