Voila, je sens le besoin de publier ce post aujourd'hui car moi j'ai commencé a apprendre le php ici sur ce site et via aussi sur un autre site il y a 1 an et demi et présentement je me débrouille assez bien pour avoir fait 2 sites avec des fonctions avancés en php dont j'en suis fier.

Quand j'ai commencé a apprendre le php, on entendait pas beaucoup parler de la PDO mais la je vois sur les forums plein de posts avec la PDO comme script php et je dois avouer que ca ne me tente pas beaucoup de ré-apprendre de nouveau le php.

mes scripts fonctionnent super biens et je ne vois pas encore en quoi le fait d'utiliser sur mes sites des scripts en PDO m'avantagerait.

C'est pourquoi je souleve ici la question

Nécessaire non. Mais pratique oui. Il n'est pas question de réapprendre le PHP, juste apprendre un autre concepte, la programmation orientée objet.

Utiliser te permettra :
- Des requêtes souvent plus optimisées et plus rapides
- Un code plus souple et plus compréhensible
- Une sécurité "automatique" (à condition de coder proprement)
- La possibilité de changer plus tard de SGBD sans trop de difficultés.

Bonsoir.
On ne code pas « en » PDO et on ne parle pas de « la » PDO mais avec. Ce n'est pas un langage à part ni une façon de coder.

Pour répondre à la question, l'API mysql va être détachée du cœur de PHP au profit de mysqli et de PDO dans les futures versions.
Les avantages de PDO par rapport aux fonctions mysql sont que PDO peut s'adapter à plusieurs SGBD, qu'il s'utilise en objet, qu'il supporte les requêtes préparées et les transactions.

BigGy : +1, mais les requêtes sont les mêmes, tu as des benchmarks récents pour PDO ?

Pour les requêtes plus optimisées je parlais du support des transactions et des requêtes préparées.

Les transactions et les requêtes préparées ne sont magiquement pas apparues avec PDO, elles ont toujours existé. (fin on se comprend)

On a pas dit ça, on a dit qu'elles n'étaient pas supportées par l'API mysql

Bah si justement, et c'est ce que moi je dis. L'API mysql n'a jamais empêché de faire des transactions ou des requêtes préparées.

Ah bon ? Comment ?

Pour les transactions,

START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summmary=@A WHERE type=1;
COMMIT;

Pour les requêtes préparées

PREPARE stmt1 FROM 'SELECT SQRT(POW(?,2) + POW(?,2)) AS hypotenuse';
SET @a = 3;
SET @b = 4;
EXECUTE stmt1 USING @a, @b;

Tu peux pas mettre ça dans un mysql_query() ça fonctionnera pas.

Nan mais en plusieurs tu peux >_>

Ah bon ? Autant pour moi. Je me coucherai moins con (si je me couche )

Citation : BigGy

Ah bon ? Autant pour moi. Je me coucherai moins con (si je me couche )

et moi alors !

Marrant : chuis totalement dans la même situation que toi... et j'ai posé une question similaire y a peu de temps (http://www.siteduzero.com/forum-83-671 [...] html#r6477208).

En même temps, je me suis posé la question parce que j'avais envie d'aller un peu plus loin en php (ça m'arrive périodiquement ;-)) et là, effectivement en regardant les nouveaux tutos, j'ai vu que PDO avait pris de l'ampleur et s'était imposé y compris dans le cours "officiel".
Et comme j'avais envie d'aller creuser un peu du côté de la POO, et que finalement l'utilisation de PDO en est une première approche assez pratique : les 2 se combinent plutôt bien.

Bref, il semblerait que ce ne soit pas qu'une mode

[edit] ah, je crois qu'il y a aussi actuellement une vague de critique contre les requêtes préparées (ou j'ai mal compris ) mais le fait est que ça donne une certaine "gueule" aux requêtes (avec l'ordre et l'organisation d'un array associatif) => à essayer

Citation : muse_stream

[edit] ah, je crois qu'il y a aussi actuellement une vague de critique contre les requêtes préparées (ou j'ai mal compris ) mais le fait est que ça donne une certaine "gueule" aux requêtes (avec l'ordre et l'organisation d'un array associatif) => à essayer

Non non pas du tout, c'est juste qu'on était pas d'accord sur le fait qu'on pouvait faire des requêtes préparées et des transaction avec l'API mysql_

alors on est trois dans cette situation. je suis pour l'instant resté à l'ancienne methode, ne comprenant pas bien PDO et ne voyant pas ce qu'elle apporte de plus. Quels avantages peut avoir une requete preparée?? et... en quoi pdo est plus clair ? 0_o

Les avantages d'une requête préparée :
- Plus rapide
- La sécurité est gérée par le moteur SQL et non par l'utilisateur.

PDO est, d'après moi, plus clair car il utilise le modèle Objet. Ceci dit c'est vrai que dans un code fonctionnel (sous entendu non objet) ça fait un peu tâche.

Fin bon, à mon avis, quitte à apprendre le concepte de POO autant en profiter pour apprendre un vrai language

Tout est faux ou à peu près
- "Plus rapide", pas vrai les réquêtes préparées sont rentables seulement si le même ordre est exécuté au moins 2 voir 3 fois (autant dire que ça n'arrive pas souvent), sinon tu perds du temps.

- "La sécurité est gérée par le moteur SQL", faux c'est la classe PDO qui s'en charge en invoquant en interne PDO::quote(), tu peux faire strictement la même chose avec mysql_* en objet...

- "PDO est, d'après moi, plus clair car il utilise le modèle Objet", euh... quelqu'un t'a interdit d'encapsulé mysql_ dans une classe ??

Citation

Fin bon, à mon avis, quitte à apprendre le concepte de POO autant en profiter pour apprendre un vrai language

?? j'ai rien compris.

PDO, mysqli, mysql, mysqlnd, c'est du pareil au même sauf besoin spécifique. Le seul argument à concidérer c'est celui de Chinoisfurax, mysql_* va être déprécié, donc il faut prévoir migrer. Idéalement pour éviter ce type de choix, tu peux passer sur Zend_Db (ou équivalent).

T.

Citation : Tracker

Tout est faux ou à peu près
- "Plus rapide", pas vrai les réquêtes préparées sont rentables seulement si le même ordre est exécuté au moins 2 voir 3 fois (autant dire que ça n'arrive pas souvent), sinon tu perds du temps.

- "La sécurité est gérée par le moteur SQL", faux c'est la classe PDO qui s'en charge en invoquant en interne PDO::quote(), tu peux faire strictement la même chose avec mysql_* en objet...

Effectivement, autant pour moi
citation rid="6519246">
- "PDO est, d'après moi, plus clair car il utilise le modèle Objet", euh... quelqu'un t'a interdit d'encapsulé mysql_ dans une classe ??</citation>
Je n'ai pas dit le contraire, mais pourquoi réinventer la roue ?

Citation : Tracker

Citation

Fin bon, à mon avis, quitte à apprendre le concepte de POO autant en profiter pour apprendre un vrai language

?? j'ai rien compris.

Je voulais dire que si on utilise PDO, autant l'utiliser dans un script écrit en Objet, sinon tu mélanges l'objet et le fonctionnel et c'est pas spécialement clair comme code. Donc je précisais à ceux intéressés par apprendre à utiliser la POO en PHP qu'à mon avis, apprendre un langage comme Python ou Java (voire Scala) serait plus utile et plus instructif.

Citation

Je n'ai pas dit le contraire, mais pourquoi réinventer la roue ?

Parce que la roue étant inventée avant PDO, cf creole par exemple. Et franchement qui à l'époque de mysql_*, à part le débutant, développait sans dbal ?

Citation

Donc je précisais à ceux intéressés par apprendre à utiliser la POO en PHP qu'à mon avis, apprendre un langage comme Python ou Java (voire Scala) serait plus utile et plus instructif

Développer Objet n'implique aucun langage, càd la réflexion est la même partout. Donc conseiller des langages marginaux est pas très cohérent, exception faite pour java ou même .Net mais là faut quand même avouer que maitriser leur librairie de classe système n'est pas donné à tout le monde, donc débuter avec ??

T.

Que ce soit avec mysql, ou avec PDO, tu peux générer ta propre classe singleton, qui gère toutes tes connections à la BDD. J’utilise PDO pour pas avoir à changer plus tard me scripts mais c'est tout.

Intéressant le débat, il est vrai qu'on ce l'ai tous poser à un moment ou un autre, je n'ai pas non plus fait mon choix définitif pour l'instant je continue à développer en procédural par habitude. Cependant je suis toujours à l'affut de nouvelles connaissances

Cependant quand on a parlé des avantages de PDO cela a été surtout pour mysql, mais si par hasard on n'utilise pas mysql ou même que l'on utilise pas de SGBD l'utilité s'en voit réduite non ? Les fonctions classiques par le système procédural peut suffire à faire un code propre et facile à maintenir non ?

J’espère ne pas dire trop de bêtises
En espérant que des personnes plus éclairé en OO puisse m'aider !

Merci.

Oui c'est possible, mais plus difficile dans le cas de grands projets.

L'organisation objet permet d'avoir des couplages faibles entre tous tes modules. C'est faisable en procédural, mais faut être super bien organisé.

Après je ne peux pas encore le savoir mais dans le milieu professionnel l'OO a l'air d'être plus utilisé que procédural non ?

Je pense d'une manière ou d'une autre à terme être obligé de connaitre les deux donc bon, la c'est plus pour ma culture personnel

Citation : private

Cependant quand on a parlé des avantages de PDO cela a été surtout pour mysql, mais si par hasard on n'utilise pas mysql ou même que l'on utilise pas de SGBD l'utilité s'en voit réduite non ?

Que tu utilises mysql, postgres ou n'importe quel autre SGDB, PDO a la même utilité (quoi que l'API pg_ soit plus poussée que mysql_ par exemple)

Par contre, si tu n'utilise pas de SGBD, l'utilité s'en voit réduite à néant que ce soit l'API mysql_ ou PDO Puisque à fortiori tu n'utilises pas de BDD.

bonjour,
l'API mysql_ correspond à MySQL 4.x.
L'API mysql_i correspond à MySQL 5.x.
L'API PDO est une couche d'abstraction (MySQL, Oracle, ...).
Comme écrit plus haut l'API MySQL est obsolète (A juste titre :-) )

Comme écrit plus haut la maintenance évolutive avec PDO est plus aisée.
Imagine que ton application passe de PHP/MySQL à PHP/Oracle.
Si ton application utilise l'API mysql_ tout est à réécrire.
Avec PDO non.
De plus si tu as utilisé des procédures stockées (ce qui est quand même la meilleure chose).

Autre nuance, l'API mysql_ ne sait pas gérer les procédures stockées avec des paramètres OUT ou INOUT. Ce que sait faire PDO.
Encore une nuance, PDO gère les Exceptions.
Et encore une autre : la plupart des FrameWorks PHP utilisent PDO.
Et une dernière, utilisez des requêtes préparées avec l'API mysql_ il faut le vouloir!

De toutes les façons je pense que seules le procédures stockées doivent être utilisées.
Toutes les applications devraient être MVC++.

Utiliser le même code avec des sgbd différents tient du fantasme, chacun ayant ses fonctions spécifiques (date, regroupement, etc... ) et ses particularités (gestion de l'héritage, requêtes CTE, etc ...). en 2092 ça sera surement possible mais d'ici là ...

Citation

Et une dernière, utilisez des requêtes préparées avec l'API mysql_ il faut le vouloir!

Une fois pour toute, tu crées un objet qui encapsule le link du driver mysql, et tu peux à l'identique de PDO fabriquer une méthode prepare générique... Le B.A-BA du dev c'est quand même de se fabriquer des outils.

Citation

De toutes les façons je pense que seules le procédures stockées doivent être utilisées.
Toutes les applications devraient être MVC++.

Rien n'est moins sûr, avec l'optimisation des navigateurs des solutions "sencha ou dojo like" risquent d'envahir le marché rendant les pluparts des sites (et leur modèle mvc X.X.X) obsolètes, c'est d'ailleurs déjà le cas.


T.

re,
ben si, avec des procédures stockées ... no problemo! puisque justement on est côté serveur et donc dans le spécifique!

J'ai bien écrit que la seule bonne structuration-programmation était de ce côté-ci!
Après, bien sûr si on commence, ou on continue :-), à écrire du code SQL dans du PHP de type VIEW, ou même CONTROLLER, alors on est pas dans la mouise!

Donc les modèles MVC + DAO et voilà!

Les API n'ont rien à foutre dans la BDD, parce que tout ne passe pas par la BDD, c'est aussi simple que ça...
Pour ce qui est de MVC et DAO chacun voit midi à sa porte.
Perso,
- MVC dès que les interfaces sont composites c'est la merde, tu fais des helpers dans tous les coins pour contourner principe, tu penses action et vue, alors que tu devrais penser API et Composants.
- DAO/ORM ok mais attention à la gestion des verrous sinon c'est casse gueule.

Mais on s'écarte du sujet de monlou...

T.

re,
"Utiliser le même code avec des sgbd différents tient du fantasme".
A quel niveau? VIEW, MODEL, CONTROLLER?
JDBC de SUN , et maintenant d'Oracle, l'a fait.
Ce sont les DAOs qui changent, tout simplement!
Ah le fantasme!