# PHP > PHP & Base de donnes > [PDO] Utilisez-vous PDO ?

## Community Management

Bonjour  tous,

Le choix du SGBD semble alimenter encore les discussion le soir prs de la chemine. Mais en plus de ce choix parfois cornlien, il existe plusieurs faons d'accder  chaque SGBD. D'une part en utilisant les fonction lies directement  ce SGBD (par exemple mysql, mysqli, postgresql), et d'autre part avec PDO.

Quel est l'intrt d'utiliser PDO alors que les outils spcifique  chaque SGBD existent ?

----------


## CinePhil

::google::  m'a emmen vers un article intitul _PDO, l'abstraction de donnes pour PHP 5_.

Aprs cette lecture, et sans avoir essay encore l'outil, je dirais que si ton application ne se servira que d'un seul SGBD, PDO n'est peut-tre pas indispensable.
Mais si par contre tu souhaites que ton application reste valable quelle que soit la base de donnes qu'il y a derrire, a semble intressant.

Ce n'est pas expliqu dans l'article mais je suppose que PDO traduit des requtes SQL pur en subtilits propres aux SGBD ?
Je pense par exemple  AUTO_INCREMENT qui existe en MySQL mais pas en PostgreSQL ni je crois en Oracle ou en SQL Server.

Je ne sais pas s'il est capable de se dbrouiller  traduire le MySQL GROUP_CONCAT en une requte donnant le mme rsultat dans d'autres SGBD.

A explorer.

Mais je crois que tu viens de lancer un dbat qui promet d'tre anim !  ::lol::

----------


## Invit1

Bonjour,

Merci de cette rponce  ::): 

En effet, cela correspond  ce que je pensais. A savoir qu'en fonction du type d'application et de la supposition d'utilisation de divers SGDB, le PDO peut  priori tre intressant...

Concernant mon application, il n'y aura que l'utilisation de Postgresql.

Nanmoins, je reste septique quant  l'opportunit de l'utilisation du PDO. Il me semble bon de souligner qu'il faille indiquer aux fonctions PDO quel SGBD est utilis... De ce fait, les lignes de code concernes s'en trouvent bien sur modifies...

N'est-il donc pas plus indiqu de crer des fonctions ou mieux des class type qui en fonction du SGBD utilis seraient charges ou non. Dans ce cas, le code principal serait alors identique et seul celui concernant le SGBD serait lui adapt...

Mais peut-tre les utilisateurs de PDO pourraient apporter leurs arguments car pour l'instant, si je comprends mieux le rle du PDO, je reste trs septique quant  son vritable intrt... D'autant comme l'indique justement CinePhil, certains SGDB permettent certains traitement et pas d'autres...

Voilou,  vos claviers  :;): 

Couik

PS : dommage, je n'ai pas tilt assez tt, un sondage aurait t aussi instructif pour connaitre l'orientation gnral des dveloppeurs...  ::P:

----------


## mon_nom_est_personne

perso je n'utilise plus que pdo pour 3 raisons:
- un standard, que l'on veuille ou non ca l'est devenue.
- flexible, la migration d'une bdd a une autre ce fait rapidement (perso je prefere quand meme recrire les requetes)
- le systeme de prepare, execute et fetchAll qui sont tout ce que j'attendais (surtout fetchAll) en standard.

----------


## Invit1

Je comprends effectivement les raisons  ::): 

Mais d'une bdd  une autre, il y a des variations quant aux possibilits de gestion des donnes ou aux capacit des bdd
Est-ce  dire alors qu'en utilisant PDO, on se cantonne dans des limites imposes en liminant de ce fait certains avantage d'offre certaine bdd ?

Car on peut supposer que je choix d'une bdd rpond  un cahier des charges tant concernant les prix que les performances

----------


## mon_nom_est_personne

Le problme c'est qu'un projet on sais toujours ou il commence jamais ou il finit.
Prenons deux ca de figure possible (dont un que j'ai vcu):
- le client se fait embobiner par un commercial de la socit A et dcide donc d'utiliser leur bdd (ou pire de passer d'un environement linux a une plateforme windows). Et bien crois moi t'es content que les transactions, executions et fetching  soient gres par appel de mthode standard.
- la solution bdd disparait du march  :;): 

Il y a aussi un avantage conceptuel et structurel, tu peux enfin reprsenter ton modle dans ton appli php (je sais les adodb etc.. mais franchement ...)

----------


## batataw

Standard:
- Parceque tu n'as besoin d'apprendre une nouvelle librarie  chaque fois que tu changes de base de donnes.
- De mme quand tu veux partager des codes sources PDO facilite la comprhension et l'intgration pour les autres.

Migration de base possible.

Fonctionnalits avances:
- Gestion des Procdures stockes natives.
- Gestion des transactions (propose une mulation si la base ne le gre pas)





> Mais d'une bdd  une autre, il y a des variations quant aux possibilits de gestion des donnes ou aux capacit des bdd
> Est-ce  dire alors qu'en utilisant PDO, on se cantonne dans des limites imposes en liminant de ce fait certains avantage d'offre certaine bdd ?


Tu peux peut-tre trouver des cas super spcifiques o il vaudra mieux passer par la librairie de la base plutt que PDO mais je n'en ai jamais rencontrs. Dans ce cas tu peux toujours crer une class qui s'occupe de ces cas.




> Car on peut supposer que je choix d'une bdd rpond  un cahier des charges tant concernant les prix que les performances


Tu peux ajouter facilit de maintenance du code.

----------


## sabotage

Le desavantage de PDO actuellement c'est quand mme la performance (au moins par rapport aux extensions mysql).

L'utilisation multi-base est quand mme tout a fait relative, les SGDB ayant des syntaxes SQL propres.

----------


## batataw

> Le desavantage de PDO actuellement c'est quand mme la performance (au moins par rapport aux extensions mysql).


A priori PDO serait plus lent cependant j'ai fait un benchmark pour en avoir le coeur net et je trouve les memes rsultats entre PDO et Mysqli. Est-ce que la derniere version de PDO a t optimis?

Mon test consistait a appeler x fois le code ci-dessous :



```

```




```

```


J'ai fait aussi des tests avec des selects aleatoires sur une tables de 10000 entres, j'ai la aussi les memes rsultats :-|

----------


## SQLpro

> Ce n'est pas expliqu dans l'article mais je suppose que PDO traduit des requtes SQL pur en subtilits propres aux SGBD ?
> Je pense par exemple  AUTO_INCREMENT qui existe en MySQL mais pas en PostgreSQL ni je crois en Oracle ou en SQL Server.


Que d'horreur :
Les auto incrments existent depuis la norme SQL:2003 qui, comme son nom l'indique date de 2003. Elle prcise que les deux lments d'auto incrmentation sont IDENTITY propre  une seule colonne d'une table et les SEQUENCE indepandant des tables.

Lisez mon livre SQL il y a une partie de chapitre la dessus.

A +

----------


## albedo0

Personnellement l'utilisation de PDO me semble indispensable, pour la portabilit du projet...

Les requtes prpares sont trs utiles et (il me semble) sont carrment performantes dans le cas de traitement par lot...

Cela reste un avis d'un utilisateur clair, mais pas expert qui va d'ailleurs de ce pas poster un message au sujet d'un problme avec PDO...

----------


## FMaz

Mais les requtes prepared, je trouve que c'est trs rare que je les utilisent plus d'une fois. Particulirement dans le cas de code orient objet.

En fait, les seuls moment ou je m'en suis servi s'tait pour insrer plusieurs champs. C'est  dire un insert dans une boucle.

Malgr tout, l'utilisation de prepare permet d'utiliser bindValue (ou param), ce qui assure la scurit du contenu face aux injections SQL.

Pour rpondre  la question, j'utilise maintenant PDO dans tous mes projets, du fait que ca va devenir un standard.

----------


## php_de_travers

Malgr le manque de documentation pour dbutant et la difficult de dbugger, PDO est devenu mon seul mode de travail de PHP avec BDD : msql et sqlite.

Le caractre assez scuris des procdures vitant les mysql_real_escape et compagnie, l'volution possible en tant que standard de dveloppement pour php6, etc... m'ont aid  faire l'effort.

----------


## Invit1

Il me semble  vous lire que cela permet bien sur la portabilit (enfin l, cela dpend de la relle ncssit) mais surtout, je note l'aspect de la scurit  ::): 

Quant aux requtes prpares, je ne maitrise pas  ::P: 

Donc au boulot, je regarde  ::): 

L'avis d'autres lecteurs/utilisateurs peut permettre aussi d'en apprendre plus  ::): 

Merci  tous
Couik

----------


## grunk

> mais surtout, je note l'aspect de la scurit


Attention tout de mme, PDO n'est pas plus sure qu'une autre extension  sql. En revanche elle permet d'accder trs facilement aux requtes prpares et propose quelques fonctions d'chappement qui , en effet, sont un plus indniable pour la scurit.

----------


## Invit1

Bonjour,

Rien n'est sur  100%

Certaines serrures se forcent en poussant fortement la porte, d'autre suppose quelques petits outils pour crocheter ces srrures et enfin d'autres demandent patience, outillage lourd et comptente...

L'objectif et bien sur de retarder et surtout de compliquer au possible les crocheteurs de serrures...

Si PDO permet en l'utilisant convenablement de retarder un peu plus les hackers de tout poil, c'est dj un plus non ngligeable  ::): 

Pour le reste de la scurit, l, beaucoup d'encre sur le sujet et beaucoup de claviers uss pour en discuter  ::mouarf:: 

Mais une chose est sre : se croire  l'abri, c'est dire "venez, entre libre"

----------


## Rakken

Alors moi j'ai un trs trs gros bmol sur PDO. 
Interopprabilit, toussa toussa, je veux bien, mais si l'outil est fini. 
J'ai eu a m'en servir il y a trois ans pour migrer un site de mysql vers oracle, ca a t une horreur sans nom (et je pse mes mots). 

Dans certaines configurations (genre un select, suivi d'un insert sur telle ou telle table...), j'ai mme obtenu des "segmentations faults", en php... J'ai mis des jours  trouver. Mon code tait bon, mais une fois sur dix, page blanche  la place de l'affichage du site. 

Si on ajoute  ca que le sql entre les diffrentes bases est aussi semblable que... du java et du javascript (c'est pareil, y a crit java des deux cots  ::aie:: ), on peut jeter toute ide d'interoprabilit. 

Pour reprendre l'ide d'auto incrment, si on cre sa base directement en php (pour un script d'install par exemple), on ne dit pas "Voila ma table, tel et tel champ de tel type, avec le premier en auto incrment => gnre moi le code sql et execute". 
Non, PDO founit juste des mthodes du genre "executeSql" (ce n'est pas forcement ce nom l, je n'ai plus tout en tte) et ca execute ton sql sur la base, au lieu d'utiliser un mysql_execute ou un oci8_execute. 
N'empeche que si le sql a t dvelopp genre en mysql, il y a de trs forte chance que le jour ou il sera lanc sur une base oracle, ca se vautre, pdo ou pas (en gros ds que c'est plus compliqu que "select * from table", et encore, si le nom de table fait plus de 30 caractres, c'est mort). 

Bref PDO, n'offre quasiment rien de plus en tant qu'interoprabilit, et a t en partie abandonn. 

Alors autant je peut comprendre l'intrt de mettre une couche entre l'appel direct des fonctions "mysql_xxx" ou "oci8_xxx" et le code mtier, autant utiliser PDO et prsenter ca comme la panace, je dis non.

----------


## sabotage

> Bref PDO, n'offre quasiment rien de plus en tant qu'interoprabilit, et a t en partie abandonn.


Il n'est pas abandonn puisqu'il est mis en avant dans PHP6.

Pour les bugs c'est bien possible, il y a aussi dans les anciennes extensions.

Pour l'interoperabilit, on en est par contre effectivement loin ; la construction du code pouvant dependre de ce qu'on peut obtenir d'une requete selon le moteur.

----------


## CinePhil

J'essaie de me mettre  PDO et je me demande si a vaut le coup que je continue...

Portabilit ?
D'aprs ce que j'ai pu lire, elle est trs relative,  cause des particularits du langage SQL implment par chaque SGBD. 
En plus je n'en ai pas besoin puisque c'est pour une application personnelle.

Performance ?
D'aprs ce que j'ai pu lire galement, il semblerait que PDO puisse tre nuisible  la rapidit de l'application.
Pour le moment, ce ne sera srement pas sensible dans mon appli mais  terme, j'aurai potentiellement des dizaines de milliers de lignes dans 27 tables, voire davantage.

Facilit ?
Je me disais que d'avoir des classes toutes faites pour grer le dialogue avec la BDD pourrait me faciliter la vie.
J'ai trouv aujourd'hui sur DVP une autre extension de PDO qui permettrait semble t-il de combler un manque pour dbugguer les requtes (je ne l'ai pas encore essay), alors qu'avec la mthode traditionnelle, un simple echo $requete donne la requte rellement envoye au serveur.

Faut-il donc que je persiste  comprendre comment fonctionne ce foutu machin parce que c'est l'avenir PHP6 ou autre raison fondamentale, ou existe t-il une classe d'accs  une BDD Postgresql plus simple que PDO ?

----------


## Kruggs

Bonjour, tout le monde
Apres lecture de ce forum, je me posais certaines question moi aussi

Dja, peut on utiliser une transaction et un prepare ? autrement dit un prepare dans une transaction ?

Pour l'extension que CinePhil fait reference, quelqu'un a test, est-bien utile ?

Avec PDO, doit-on tout de meme mettre des mysql_real_escape ou des "$pattern 		= '`('.preg_quote("".$param["parameter"]).')([\s]{0,}[,]{0,})`i';" comme fait dans l'extension ?

Sur un gros projet, je vais devoir utiliser du MySQL,DB2,LDAP, donc je pensais prendre PDO pour MySQL, db2cli pour db2 et l'autre module pour ldap ( j'ai zaper le nom ), ai-je des risques de perdre en performance avec le pdo sachant que je gere des tables qui varie de 10 a 1 000 000 de nuplets! lol

Merci d'avance  ::):

----------


## pc.bertineau

J'utilise PDO par dfaut, n'ayant travaill que sur PostGre et MySQL, 2 SGBD plutt bien supports/interfacs. J'essaie du coup d'utiliser avec parcimonie les particularits SQL propres au SGBD sinon a sert  rien...

Nanmoins je garde toujours sous le coude une connexion type mysql_connect pour traiter des cas spciaux :
Requte spcifiquement accepte par un SGBD,Jointures sur des tables de bases diffrentes (obligations de dclarer une connexion PDO sur une DB donne),Problme de perf et mme bug technique (dcouvert sur une version 5.1.67 pour Linux, voir topic ddi).

----------


## FMaz

*tre bien outill*
Le problme que beaucoup semblent avoir avec PDO est son manque d'intuitivit. Par dfaut, les erreurs semblent ne pas tre rapport, on ne sais pas trop pourquoi ca marche et pourquoi ca cesse de fonctionner.

Donc oui, au dbut il est assez compliqu d'utiliser PDO. Mais la bonne nouvelle c'est qu'une fois vos "outils" dvelopps ( une classe connexionManager offrant des fonctions de dbuggage par exemple ), vous pourrez la r-utiliser pour tous vos projet, et PDO deviens presqu'un charme.

PDO est comme un garage aprs un dmnagement, il faut le mettre  notre got pour s'y retrouver.


*Les pommes avec les pommes*
Cependant, il faut comparer des pommes avec des pommes. Je trouve un peu injuste de comparer mysql_connect avec PDO, et de dire que le premier est plus rapide. Oui, il faut s'y attendre vu que PDO est une couche supplmentaire. Ca me semble donc normal que du fait qu'il apporte des fonctionnalits supplmentaires, il soit plus rapide.

Si vous voulez rellement comparer des concurrent, il faudrait y aller PDO avec MDB2 (pear). Et dans ce cas on se rend vite compte que PDO est assez rapide, du fait qu'il soit compil (si ma mmoire est bonnes).


*Mode de connexion privilgi pour PHP6*
Aussi, j'ai dj lu quelque part que PDO allait tre le mode de connexion par dfaut dans PHP6. C'est donc intressant de penser que les projets que nous commenons  dvelopper seront plus facile  migrer dans quelques annes.





> Avec PDO, doit-on tout de meme mettre des mysql_real_escape


Si tu "bind" tes paramtres, non, car PDO dtecte la base de donnes que tu utilise, et va appeler lui-mme la fonction approprie pour la base de donnes que tu utilise.

Si tu veux injecter directement les variables dans la requte: oui, car c'est une chaine de caractre comme une autre.

*Bugs actuels:*

*>>* Ne pas binder les valeurs de LIMIT

 moins que ca ai t rsolu dans les version trs rcentes, vitez de binder vos valeurs pour des LIMIT:


```
LIMIT ?,?
```

PDO semble  un petit bug  ce niveau et englobe les valeurs dans des guillemet. Contrairement aux autres champs, MySQL ne converti pas les strings en int pour le paramtre LIMIT.

Vous devez donc injecter les valeurs de faon traditionnelle directement dans la string qui contient votre moule de requte:


```
$query = 'SELECT * FROM aaa WHERE id=? LIMIT ' . (int)$from . ',' . (int)$length . ';';
```

*>>* Pas de fonction *_num_rows()
Une raison rationnelle et explique existe, mais tout ce que j'en ai retenu c'est qu'il fallait faire une requte avec un COUNT() ou un count($arr) sur le rsultat d'un fetchAll pour avoir le nombre de ligne d'un rsultat.

C'est un peu plus long, mais dans 95% des cas ca ne me complique pas rellement la tche.

*>>* closeCursor() n'est pas toujours efficace
Si vous r-utilisez une variable de requte prpare pour une 2ieme requte, il arrive parfois que malgr un closeCursor, la variable ne soit pas correctement r-initialis.
Prenez l'habitude de terminer avec $prep = NULL; , ce qui libre rellement la variable de son contenu.

----------


## Rakken

Le problme est que cette liste des bugs actuels n'est hlas pas exhaustive.
Allez voir sur php.net la page "PDO Oracle", a fait peur... pour un outil qui se veut tre utilis pour s'abstraire en partie de la base de donne. (Perso, je n'ai jamais boss en web rellement que sur deux bases, MySql et Oracle, si l'une des deux ne fonctionne pas (ne soyons pas mauvaise langue, disons juste "trs mal") avec pdo...  quoi bon ?).
Et pour ce que j'en sais, ce n'est plus maintenu, sur PECL la date de la derniere mise  jours est de 2005.
Qu'ils veulent mettre ca en avant pour PHP6, pourquoi pas, mais pour l'instant, c'est du bricolage.

Juste un exemple, le type CLOB n'est mme pas support par pdo-oci (il y a bien les objets LOB, mais ils fonctionnent comme des fichiers, super pratique quand on veut faire un insert avec un texte de 5000 caractres, il insrer la ligne puis ouvrir le champ comme un fichier et crire dedans  coup de write  ::aie:: ).
Et a, c'est sans compter les seg fault (si si si), qui se produisent dans certains cas foireux (je n'ai plus le code en question, mais une fois sur deux, ma page web devenait compltement blanche parce que l'appel  pdo_oci provoquait un plantage).

Bref, je persiste, PDO en l'tat actuel, je n'en veux pas. Se faire une petite classe d'abstraction  la main qui appelle directement les mysql_xxx et autres est tout aussi efficace et, mme si c'est trange, plus robuste. 

Tu parles d'une classe  rajouter par dessus PDO pour le rentre  peu prs utilisable, gnial, alors puisqu'il y a des trucs qu'il faut rajouter de toute manire, pourquoi s'encombrer de PDO ?

----------


## CinePhil

Je m'initie dsormais au Zend Framework et toute l'abstraction qu'il contient me fait un peu peur parce que j'aime bien avoir la main sur les requtes.

Zend Framework utilise t-il PDO ou directement les mysql_X, pg_X... ?

----------


## sabotage

> t pour ce que j'en sais, ce n'est plus maintenu, sur PECL la date de la derniere mise  jours est de 2005.


PDO ne fait plus partie de PECL.
Je ne saurais pas me prononcer sur Oracle mais concernant mysql et mssql, je n'ai rencontr que peu de problme et des bugs existants sont corrigs.

Pour le sujet de la production d'un code universel, comme on l'a dit, le problme se situe bien en amont de PDO puisque les diffrents moteurs ne parlent pas la mme langue.
Un des interts de PDO est que l'criture des traitements est uniforme, une couche d'abstraction quoi  :;):

----------


## FMaz

> ma page web devenait compltement blanche parce que l'appel  pdo_oci provoquait un plantage).


Gnralement quand ca m'arrivait, s'tait parce que:
1- Je n'avais pas configur PDO pour afficher les erreurs
2- Je n'avais pas correctement r-initialis la variable contenant le statement.

Ce qu'il faut comprendre, c,est que par dfaut, PDO est en mode "production", et non en mode "dveloppement". Si on veux afficher les erreurs, il faut rajouter un paramtre pour lui dire de faon explicite.





> Tu parles d'une classe  rajouter par dessus PDO pour le rentre  peu prs utilisable, gnial, alors puisqu'il y a des trucs qu'il faut rajouter de toute manire, pourquoi s'encombrer de PDO ?


Ca c'est peu de la mauvaise foi. La classe  rajouter par dessus sert uniquement  pouvoir mieux dbugger. Elle n'est pas requise en production.

De plus tu parle d'un session manager, et bien ce n'est pas le rle de PDO ni de n'importe quel autre mode de connexion. Pour finir, avoir un session manager n'est absolument pas obligatoire.

Moi j'aime mieux ca, car ca me permet d'accder  n'importe laquelle de mes session peu-importe le scope dans lequel je suis, et ca me permet aussi d'automatiser ma gestion des erreurs.

Je ne vois pas en quoi l'envoi de email en cas de problme de requte devrait tre pris nativement en charge par PDO, ou n'importe quel autre mode de connexion.





> Pour le sujet de la production d'un code universel, comme on l'a dit, le problme se situe bien en amont de PDO puisque les diffrents moteurs ne parlent pas la mme langue.


Exact, entre beaucoup de systmes, il y aura des diffrences. Mais PDO permet de mcher une bonne partie du travail de base pour les language avec une syntaxe SQL.

Aprs, pour le --somme toute petit-- pourcentage restant, avec ou sans PDO, vous devrez traiter le cas manuellement de toute faon.

----------


## pc.bertineau

> Aprs, pour le --somme toute petit-- pourcentage restant, avec ou sans PDO, vous devrez traiter le cas manuellement de toute faon.


C'est peut-tre le ct "pervers" de PDO : laisser croire que l'interoprabilit est possible. Mais pour du CRUD de base, il y a un intrt certain  l'utiliser.

----------


## FMaz

Effectivement, beaucoup de gens semblent penser que toute requte imaginable sera fonctionnelle et traduite  100%. Ce n'est malheureusement pas la ralit du moment, et je doute que ca soit possible un jour, peu-importe la couche d'abstraction.

Personnellement, je trouve PDO pratique car je n'ai pas  faire ce qui suit, ni  programmer moi-mme une classe pour s'en occuper automatiquement (ce qui devrait tre interprt, donc plus lent que PDO qui est compil nativement)


```

```

PDO automatise ce genre d'opration de base  trs bas niveau. Pour moi (et je ne suis pas tous), c'est un des gros avantage de PDO.

Un autre autre avantage est la possibilit de pouvoir binder des valeurs, ca fait des requtes plus propres. Certaines personnes pourraient dire que sprintf() peut aussi placer des valeurs dans la chaine, mais le problme c'est qu'avec 35 valeurs  placer pour un gros INSERT, on s'y perd vite si on ne peux pas nommer les 'tags'.

PDO m'oblige  avoir un code plus propre, et chaque requte deviens un bloc de code bien dfini.


Pour finir, je dirais qu'il fut un temps ou je dtestais la POO. J'affirmais qu'avec une bonne organisation de fichier, et une bonne convention de nommage, s'tait inutile. Je poussais mme la critique en affirmant que vu qu'en procdurale pure, on ne segmentait pas tout le code en l'isolant dans des mthodes d'objets, on pouvais plus facilement optimiser ce code afin de grouper plusieurs actions en mme temps.

Je pense toujours que j'ai partiellement raison. Cependant je pense que la POO apporte des avantages non-ngligeable du point de vu de l'ergonomie, du contrle d'accs (private, protected, public), et une foule d'autres petits avantages pas ncessairement ncssaires, mais tout de mme trs apprci et qui facilitent le dveloppement.

PDO, c'est comme la POO:  strictement parler, c'est pas essentiel, mais quand on apprend  aimer toutes ces petites subtilits, on ne veux plus la laisser partir. (9 jours plus tt et je terminais sur une bonne blague  ::roll:: )

Si mon paragraphe sur l'amour ne vous convainc pas, voici une compilation d'extraits portant sur PHP6:



> Suppressions
> 
> Cette fois-ci, PHP6 fait le mnage en supprimant (pour ceux qui ne savent pas) : Les Register globals, Magic quotes, Safe Mode, PECL (qui pourra tre tlcharg, mais absent dans le package officiel de PHP6).
> 
> Certaines extensions les moins utilises migrent vers PECL mais aussi celles des bases de donnes laissant cette fois la place  PDO que nous introduirons plus tard...


Src.: http://www.slashon.com/index.php/200...-_Vous_adapter




> Dans cette nouvelle version de PHP, les fonctions telles que mysql_connect seront toutes dportes dans PECL (un dpt dextensions PHP non obligatoires) pour laisser la place  PDO. Ce changement majeur va forcer bon nombre de dveloppeurs  se mettre  jour, et  ne plus utiliser les fonctions de mysql_* au profit de lextension PDO.


src: http://manuel-esteban.com/?p=31

----------


## sabotage

Oui enfin c'est un forceage au rythme du web : dans 10ans on aura toujours des hebergeurs avec l'extension mysql (PHP5 a 6 ans).

----------


## Rakken

En mme temps, virer de base toutes les extentions mysql_* c'est rendre incompatible l'immense majorit des sites utilisant une base mysql. 
Sur une appli bien faite (avec une classe d'abstraction qui concentre tous les appels au fonctions mysql_* au mme endroit), ce n'est pas forcement difficile de migrer, mais pour le reste... 
A vouloir faire "trop" propre, je me demande si php6 ne va pas tout simplement rebuter. Il n'y a qu'a voir la lenteur de migration entre php4 et php5 alors que php5 tait vraiment nickel en termes de rtrocompatiblit (sur une dizaine de sites de taille parfois importante que j'ai eu  migrer, aucun n'a pris plus d'une journe, et la moiti d'entre eux n'ont ncessit aucun changement).
'fin bref, puisqu'il faut manger du PDO, je mangerai du pdo. Encore une fois, avec une petite couche bien faite dessus, on ne se rend plus compte de ce qu'on utilise.

----------


## FMaz

> J'essaie de me mettre  PDO et je me demande si a vaut le coup que je continue...
> 
> Portabilit ?
> D'aprs ce que j'ai pu lire, elle est trs relative,  cause des particularits du langage SQL implment par chaque SGBD. 
> En plus je n'en ai pas besoin puisque c'est pour une application personnelle.


La portabilit se situe au niveau des fonctions d'accs, pas au niveau de la formation des requtes SQL.
Il s'agit de 2 couches d'abstraction bien distinctes.

En ce qui concerne la difficult d'exploitation avec MSSQL ou Oracle, il faut savoir que oui, ces connecteur en particuliers ne sont pas encore complt. Mais comme PDO est la direction dans laquelle PHP va voluer, c'est un bon rflexe de l'utiliser afin que dans quelques annes, la portabilit s'largisse au niveau des autres SGBD.

C'est comme le CSS3: On en met, et dans quelques temps, les vieux site auront des fonctionnalit de plus qui apparaitrons :p





> Performance ?
> D'aprs ce que j'ai pu lire galement, il semblerait que PDO puisse tre nuisible  la rapidit de l'application.
> Pour le moment, ce ne sera srement pas sensible dans mon appli mais  terme, j'aurai potentiellement des dizaines de milliers de lignes dans 27 tables, voire davantage.


Moins que n'importe quel autre mcanisme d'abstraction des fonctions d'accs  la base de donnes, car c'est la seule extention qui est compile nativement.

Aprs il faut comparer des pommes avec des pommes, et savoir relativiser les "moins performant".

Fabien potencier expliquait assez bien cette ralit lors d'une confrence lorsqu'il comparait la rapidit de Symfony  faire des hello world. La facon la plus rapide de faire un hello world, c'est die('hello world');

Mais on repassera pour la souplesse du code.




> Facilit ?
> Je me disais que d'avoir des classes toutes faites pour grer le dialogue avec la BDD pourrait me faciliter la vie.
> J'ai trouv aujourd'hui sur DVP une autre extension de PDO qui permettrait semble t-il de combler un manque pour dbugguer les requtes (je ne l'ai pas encore essay), alors qu'avec la mthode traditionnelle, un simple echo $requete donne la requte rellement envoye au serveur.


Oui, c'est  mon avis la faiblesse #1 de PDO.
Ceci tant dis, dans quel cas est-ce ncssaire d'avoir cette information ?
- Au moment de la cration de la requte
--> Cre la dans PHPMyAdmin
- En cas d'erreur.
--> L'erreur retourn par MySQL retourne la portion provoquant l'erreur. Il suffit de capturer l'exception.

Mais je suis d'accord, ce n'est pas parfait, et je l'ai dj dis dans un autre sujet.

Ensuite lorsqu'on comprend bien le fonctionnement des placeholders, on comprend assez vite que d'avoir la sortie complte de la requte est inutile, puisque le bug ne proviendra pas de la valeur place par le place holder. Certe, il faut faire confiance  PDO, et bien savoir ce que les diffrents PDO: ::P: ARAM_xxx font.

L'extrait de l'erreur lanc par mysql suffit gnralement  remplir le trou d'information manquante s'il y en as un.

Et puis finalement, vous compar l'excution d'une requte simple avec une requte prpare. Avez-vous dj fait des requtes prpar avec mysql_ ou mysqli_ ?

... parceque query et exec en PDO retourne aussi le rsultat complet, mais ce n'est pas des requte prpars.

Donc en somme, une partie du problme est que vous utilis une autre facon de transiger avec MySQL. Une requte prpare se fait en 2 partie, et seul MySQL assemble les 2 rsultats. Riens  voir avec PDO.

Encore une fois, comparez les pommes  des pommes.




> Faut-il donc que je persiste  comprendre comment fonctionne ce foutu machin parce que c'est l'avenir PHP6 ou autre raison fondamentale, ou existe t-il une classe d'accs  une BDD Postgresql plus simple que PDO ?


Sans aucun doute. PDO vaux tout  fait la peine d'tre appris malgr qu'il ne soit pas aussi intuitif au dpart que mysql_ ou mysqli_ .

Le code sera plus propre, plus scur, et normalis.

Maintenant que je me suis fait un connexion manager et que j'ai dvelopp mes classes tendu de PDO et PDOStatement et intgr une gestion automatis des erreurs: je suis vraiment heureux, ma vie s'est grandement amliore. PDO  mme gurrit ma grippe.


Donc voil, amusez-vous !

----------


## FMaz

> En mme temps, virer de base toutes les extentions mysql_* c'est rendre incompatible l'immense majorit des sites utilisant une base mysql. 
> Sur une appli bien faite (avec une classe d'abstraction qui concentre tous les appels au fonctions mysql_* au mme endroit), ce n'est pas forcement difficile de migrer, mais pour le reste... 
> A vouloir faire "trop" propre, je me demande si php6 ne va pas tout simplement rebuter. Il n'y a qu'a voir la lenteur de migration entre php4 et php5 alors que php5 tait vraiment nickel en termes de rtrocompatiblit (sur une dizaine de sites de taille parfois importante que j'ai eu  migrer, aucun n'a pris plus d'une journe, et la moiti d'entre eux n'ont ncessit aucun changement).
> 'fin bref, puisqu'il faut manger du PDO, je mangerai du pdo. Encore une fois, avec une petite couche bien faite dessus, on ne se rend plus compte de ce qu'on utilise.



Probablement que les hbergeur vont offrir les 2 types d'hbergement: 5 ou 6.

mais beaucoup des fonctionnalit de PHP6 ont t, ou vont tre prvu pour des version de php 5.x. Par exemple, php 5.3 propose beaucoup de fonctions qui taient initialement prvu pour PHP6, et dj certaines fonction lancent des warning E_DEPRECATE. Comme les fonction ereg_* je crois.

Oui PHP6 va clasher, mais c'est une bonne chose, car PHP souffre de la rputation d'tre un language amateur. Il n'est pas toujours pris au srieux pour les gros dveloppement d'envergure importante.

... et c'est principalement du au fait que plusieurs personnes programment mal et profite du fait que PHP soit laxiste pour faire passer n'importe quelle cochonnerie comme du code "fonctionnel".

Les magic quote ont t, selon-moi, le point tournant ou l'quipe de PHP  dcid de mettre un frein  "faciliter la programmation amateur", et s'est dit qu'il fallait au contraire r-axer le projet vers un avenir plus srieux.

Donc c'est vrai que PHP6 ne sera pas aussi largement dploy que les versions prcdentes si les conditions actuelles sont maintenues. Par contre, je pense que dans la culture du milieu, on vera apparaitre:

PHP 6 = professionel
PHP 5 = amateur

==> Si l'application ne migre pas, c'est un indicateur d'une programmation bcle, ou d'un programmeur peu comptent.


Note: Je suis le premier qui devra sans doute adapter certaines parties de son code  :;):  Mais je vous jure que j'ai t ammen  travailler sur des horreurs de programmation, et que l'avnement de normes plus stricte est pour moi un vritable soulagement.

----------


## sabotage

Je ne comprends pas bien ce que tu dis.
Tu veux dire que les requtes prpares avec mysqli ou avec PDO ne fonctionnement pas sur le meme principe ?

----------


## FMaz

Ce que je dis, c'est que les gens comparent des requtes directes (mysql_query) avec les requtes prpars de PDO.

Dans un cas, on envoie une unique chaine string  MySQL. videmment que c'est facile de l'afficher.
Dans l'autre cas, c'est un autre concept: c'est une requte prpar:
On envoi un "moule" de requte au serveur, qui la stock temporairement j'imagine (je connais pas les dtails internes), puis dans un second temps, on envoi les paramtres et l'ordre dans lequel les placer les valeurs (dans les place holder), et d'excuter la requte ainsi forge.

Alors pour obtenir la requte complte et construite, il faudrait que MySQL retourne le rsultat de la compilation qu'il fait.

-------

Pour faire une analogie, c'est comme si on reprochait aux Vues MySQL ne ne pas nous laisser facilement dbugger la requte qui se cache derrire la vue...


Edit:

En quoi ce code MySQLi permet-il d'avantage de dbugger la valeur totale d'une requte que PDO ?:



```

```

Je ne vois pas plus comment vous arrivez  obtenir:


```

```


... et je me demande mme au moins une personne sur la terre a dj fait des prepared statement avec mysql_ tellement c'est manuel et pnible.

----------


## sabotage

> En quoi ce code MySQLi permet-il d'avantage de dbugger la valeur totale d'une requte que PDO ?:


Oui donc mysqli et PDO pour les requtes prpares c'est la mme chose.

----------


## FMaz

> Oui donc mysqli et PDO pour les requtes prpares c'est la mme chose.


Exact.
C'est pour cette raison que je trouvais les gens dur dans leurs critiques envers PDO, qui souffre exactement du mme dfaut que les autres.

----------


## Invit

Bonjour,
J'ais comme l'impression que tout le monde a raison et tout le monde a tort  ::oops:: 
*Mysqli et pdo tel que je le vois utilis partout font la mme chose* 

Effectivement puisque je ne sais mme pas si j'ais vu une seule fois ici "un vrais prpare de PDO" a savoir que dans la log "SQL" nous trouvons 
l'appel du prepare, (une ligne)
puis  l'exec  (une autre ligne par exec) !

Faute de quoi PDO perd 50% de son intret  ::?: 

Oui tout est dans 


```
$dbd->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
```

Avant de poster j'ais recherch, il me semble que JulP a abord le sujet  ::oops::

----------


## FMaz

mon sens, il est assez rare que les gens utilisent prepare pour des raisons de pure-performance.

La raison principale pourquoi prepare est autant "fortement suggr", c'est pour prvenir le plus possible les injection SQL, tel que l'OWASP l'avait d'ailleurs suggr.

Donc oui, trs utile  savoir (mme moi je l'ignorais), mais pas si "choquant", vu qu'au final ca ne change pas grand chose... mme qu'un prepare pour une seule excution, c'est plus lent qu'une requte direct...  ::roll::

----------


## stealth35

avec _PDO_ on peut crer notre propre pilote en _PHP_  ::ccool:: 
http://pecl.php.net/package/pdo_user

c'est ici que les constantes PDO::PARAM_EVT_* seront utilises

----------

