Version imprimable
Bonjour à tous,
Le choix du SGBD semble alimenter encore les discussion le soir près de la cheminée. Mais en plus de ce choix parfois cornélien, il existe plusieurs façons d'accéder à chaque SGBD. D'une part en utilisant les fonction liées directement à ce SGBD (par exemple mysql, mysqli, postgresql), et d'autre part avec PDO.
Quel est l'intérêt d'utiliser PDO alors que les outils spécifique à chaque SGBD existent ?
:google: m'a emmené vers un article intitulé PDO, l'abstraction de données pour PHP 5.
Après 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 données qu'il y a derrière, ça semble intéressant.
Ce n'est pas expliqué dans l'article mais je suppose que PDO traduit des requêtes SQL pur en subtilités 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 débrouiller à traduire le MySQL GROUP_CONCAT en une requête donnant le même résultat dans d'autres SGBD.
A explorer.
Mais je crois que tu viens de lancer un débat qui promet d'être animé ! :lol:
Bonjour,
Merci de cette réponce :)
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 intéressant...
Concernant mon application, il n'y aura que l'utilisation de Postgresql.
Néanmoins, 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 concernées s'en trouvent bien sur modifiées...
N'est-il donc pas plus indiqué de créer des fonctions ou mieux des class type qui en fonction du SGBD utilisé seraient chargées 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 rôle du PDO, je reste très septique quant à son véritable intérêt... 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 tôt, un sondage aurait été aussi instructif pour connaitre l'orientation général des développeurs... :P
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.
Je comprends effectivement les raisons :)
Mais d'une bdd à une autre, il y a des variations quant aux possibilités de gestion des données ou aux capacité des bdd
Est-ce à dire alors qu'en utilisant PDO, on se cantonne dans des limites imposées en éliminant de ce fait certains avantage d'offre certaine bdd ?
Car on peut supposer que je choix d'une bdd répond à un cahier des charges tant concernant les prix que les performances
Le problème 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 vécu):
- le client se fait embobiner par un commercial de la société A et décide 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 gérées par appel de méthode standard.
- la solution bdd disparait du marché ;)
Il y a aussi un avantage conceptuel et structurel, tu peux enfin représenter ton modèle dans ton appli php (je sais les adodb etc.. mais franchement ...)
Standard:
- Parceque tu n'as besoin d'apprendre une nouvelle librarie à chaque fois que tu changes de base de données.
- De même quand tu veux partager des codes sources PDO facilite la compréhension et l'intégration pour les autres.
Migration de base possible.
Fonctionnalités avancées:
- Gestion des Procédures stockées natives.
- Gestion des transactions (propose une émulation si la base ne le gère pas)
Tu peux peut-être trouver des cas super spécifiques où il vaudra mieux passer par la librairie de la base plutôt que PDO mais je n'en ai jamais rencontrés. Dans ce cas tu peux toujours créer une class qui s'occupe de ces cas.Citation:
Mais d'une bdd à une autre, il y a des variations quant aux possibilités de gestion des données ou aux capacité des bdd
Est-ce à dire alors qu'en utilisant PDO, on se cantonne dans des limites imposées en éliminant de ce fait certains avantage d'offre certaine bdd ?
Tu peux ajouter facilité de maintenance du code.Citation:
Car on peut supposer que je choix d'une bdd répond à un cahier des charges tant concernant les prix que les performances
Le desavantage de PDO actuellement c'est quand même la performance (au moins par rapport aux extensions mysql).
L'utilisation multi-base est quand même tout a fait relative, les SGDB ayant des syntaxes SQL propres.
A priori PDO serait plus lent cependant j'ai fait un benchmark pour en avoir le coeur net et je trouve les memes résultats entre PDO et Mysqli. Est-ce que la derniere version de PDO a été optimisé?Citation:
Envoyé par sabotage
Mon test consistait a appeler x fois le code ci-dessous :
Code:
2
3
4
5
6
7
Code:
2
3
4
5
6
7
J'ai fait aussi des tests avec des selects aleatoires sur une tables de 10000 entrées, j'ai la aussi les memes résultats :-|
Que d'horreur :Citation:
Ce n'est pas expliqué dans l'article mais je suppose que PDO traduit des requêtes SQL pur en subtilités 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.
Les auto incréments existent depuis la norme SQL:2003 qui, comme son nom l'indique date de 2003. Elle précise que les deux éléments d'auto incrémentation 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 +
Personnellement l'utilisation de PDO me semble indispensable, pour la portabilité du projet...
Les requêtes préparées sont très utiles et (il me semble) sont carrément 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 problème avec PDO...
Mais les requêtes prepared, je trouve que c'est très rare que je les utilisent plus d'une fois. Particulièrement dans le cas de code orienté objet.
En fait, les seuls moment ou je m'en suis servi s'était pour insérer 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 sécurité du contenu face aux injections SQL.
Pour répondre à la question, j'utilise maintenant PDO dans tous mes projets, du fait que ca va devenir un standard.
Malgré le manque de documentation pour débutant et la difficulté de débugger, PDO est devenu mon seul mode de travail de PHP avec BDD : msql et sqlite.
Le caractère assez sécurisé des procédures évitant les mysql_real_escape et compagnie, l'évolution possible en tant que standard de développement pour php6, etc... m'ont aidé à faire l'effort.
Il me semble à vous lire que cela permet bien sur la portabilité (enfin là, cela dépend de la réelle nécéssité) mais surtout, je note l'aspect de la sécurité :)
Quant aux requêtes préparées, 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
Attention tout de même, PDO n'est pas plus sure qu'une autre extension sql. En revanche elle permet d'accéder très facilement aux requêtes préparées et propose quelques fonctions d'échappement qui , en effet, sont un plus indéniable pour la sécurité.Citation:
Envoyé par couik
Bonjour,
Rien n'est sur à 100%
Certaines serrures se forcent en poussant fortement la porte, d'autre suppose quelques petits outils pour crocheter ces sérrures et enfin d'autres demandent patience, outillage lourd et compétente...
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 déjà un plus non négligeable :)
Pour le reste de la sécurité, là, beaucoup d'encre sur le sujet et beaucoup de claviers usés pour en discuter :mouarf:
Mais une chose est sûre : se croire à l'abri, c'est dire "venez, entrée libre"
Alors moi j'ai un très très gros bémol sur PDO.
Interoppérabilité, 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 pèse mes mots).
Dans certaines configurations (genre un select, suivi d'un insert sur telle ou telle table...), j'ai même 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 différentes bases est aussi semblable que... du java et du javascript (c'est pareil, y a écrit java des deux cotés :aie:), on peut jeter toute idée d'interopérabilité.
Pour reprendre l'idée d'auto incrément, si on crée 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 incrément => génère moi le code sql et execute".
Non, PDO founit juste des méthodes du genre "executeSql" (ce n'est pas forcement ce nom là, je n'ai plus tout en tête) 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é développé genre en mysql, il y a de très forte chance que le jour ou il sera lancé sur une base oracle, ca se vautre, pdo ou pas (en gros dès que c'est plus compliqué que "select * from table", et encore, si le nom de table fait plus de 30 caractères, c'est mort).
Bref PDO, n'offre quasiment rien de plus en tant qu'interopérabilité, et a été en partie abandonné.
Alors autant je peut comprendre l'intérêt de mettre une couche entre l'appel direct des fonctions "mysql_xxx" ou "oci8_xxx" et le code métier, autant utiliser PDO et présenter ca comme la panacée, je dis non.
Il n'est pas abandonné puisqu'il est mis en avant dans PHP6.Citation:
Bref PDO, n'offre quasiment rien de plus en tant qu'interopérabilité, et a été en partie abandonné.
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.
J'essaie de me mettre à PDO et je me demande si ça vaut le coup que je continue...
Portabilité ?
D'après ce que j'ai pu lire, elle est très relative, à cause des particularités du langage SQL implémenté par chaque SGBD.
En plus je n'en ai pas besoin puisque c'est pour une application personnelle.
Performance ?
D'après 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 sûrement 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 gérer 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 débugguer les requêtes (je ne l'ai pas encore essayé), alors qu'avec la méthode traditionnelle, un simple echo $requete donne la requête réellement envoyée 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'accès à une BDD Postgresql plus simple que PDO ?
Bonjour, tout le monde
Apres lecture de ce forum, je me posais certaines question moi aussi
Déja, 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 :)
J'utilise PDO par défaut, n'ayant travaillé que sur PostGre et MySQL, 2 SGBD plutôt bien supportés/interfacés. J'essaie du coup d'utiliser avec parcimonie les particularités SQL propres au SGBD sinon ça sert à rien...
Néanmoins je garde toujours sous le coude une connexion type mysql_connect pour traiter des cas spéciaux :
- Requête spécifiquement acceptée par un SGBD,
- Jointures sur des tables de bases différentes (obligations de déclarer une connexion PDO sur une DB donnée),
- Problème de perf et même bug technique (découvert sur une version 5.1.67 pour Linux, voir topic dédié).
Être bien outillé
Le problème que beaucoup semblent avoir avec PDO est son manque d'intuitivité. Par défaut, les erreurs semblent ne pas être rapporté, on ne sais pas trop pourquoi ca marche et pourquoi ca cesse de fonctionner.
Donc oui, au début il est assez compliqué d'utiliser PDO. Mais la bonne nouvelle c'est qu'une fois vos "outils" développés ( une classe connexionManager offrant des fonctions de débuggage par exemple ), vous pourrez la ré-utiliser pour tous vos projet, et PDO deviens presqu'un charme.
PDO est comme un garage après un déménagement, il faut le mettre à notre goût 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 supplémentaire. Ca me semble donc normal que du fait qu'il apporte des fonctionnalités supplémentaires, il soit plus rapide.
Si vous voulez réellement 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 mémoire est bonnes).
Mode de connexion privilégié pour PHP6
Aussi, j'ai déjà lu quelque part que PDO allait être le mode de connexion par défaut dans PHP6. C'est donc intéressant de penser que les projets que nous commençons à développer seront plus facile à migrer dans quelques années.
Si tu "bind" tes paramètres, non, car PDO détecte la base de données que tu utilise, et va appeler lui-même la fonction appropriée pour la base de données que tu utilise.Citation:
Avec PDO, doit-on tout de meme mettre des mysql_real_escape
Si tu veux injecter directement les variables dans la requête: oui, car c'est une chaine de caractère comme une autre.
Bugs actuels:
>> Ne pas binder les valeurs de LIMIT
À moins que ca ai été résolu dans les version très récentes, évitez de binder vos valeurs pour des 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 paramètre LIMIT.Code:LIMIT ?,?
Vous devez donc injecter les valeurs de façon traditionnelle directement dans la string qui contient votre moule de requête:
>> Pas de fonction *_num_rows()Code:$query = 'SELECT * FROM aaa WHERE id=? LIMIT ' . (int)$from . ',' . (int)$length . ';';
Une raison rationnelle et expliquée existe, mais tout ce que j'en ai retenu c'est qu'il fallait faire une requête avec un COUNT() ou un count($arr) sur le résultat d'un fetchAll pour avoir le nombre de ligne d'un résultat.
C'est un peu plus long, mais dans 95% des cas ca ne me complique pas réellement la tâche.
>> closeCursor() n'est pas toujours efficace
Si vous ré-utilisez une variable de requête préparée pour une 2ieme requête, 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 libère réellement la variable de son contenu.
Le problème est que cette liste des bugs actuels n'est hélas 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 donnée. (Perso, je n'ai jamais bossé en web réellement que sur deux bases, MySql et Oracle, si l'une des deux ne fonctionne pas (ne soyons pas mauvaise langue, disons juste "très 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 même 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 caractères, il insérer 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 complètement 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, même si c'est étrange, plus robuste.
Tu parles d'une classe à rajouter par dessus PDO pour le rentre à peu prés utilisable, génial, alors puisqu'il y a des trucs qu'il faut rajouter de toute manière, pourquoi s'encombrer de PDO ?
Je m'initie désormais 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 requêtes.
Zend Framework utilise t-il PDO ou directement les mysql_X, pg_X... ?
PDO ne fait plus partie de PECL.Citation:
t pour ce que j'en sais, ce n'est plus maintenu, sur PECL la date de la derniere mise à jours est de 2005.
Je ne saurais pas me prononcer sur Oracle mais concernant mysql et mssql, je n'ai rencontré que peu de problème et des bugs existants sont corrigés.
Pour le sujet de la production d'un code universel, comme on l'a dit, le problème se situe bien en amont de PDO puisque les différents moteurs ne parlent pas la même langue.
Un des interêts de PDO est que l'écriture des traitements est uniforme, une couche d'abstraction quoi ;)
Généralement quand ca m'arrivait, s'était parce que:Citation:
ma page web devenait complètement blanche parce que l'appel à pdo_oci provoquait un plantage).
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 défaut, PDO est en mode "production", et non en mode "développement". Si on veux afficher les erreurs, il faut rajouter un paramètre pour lui dire de façon explicite.
Ca c'est peu de la mauvaise foi. La classe à rajouter par dessus sert uniquement à pouvoir mieux débugger. Elle n'est pas requise en production.Citation:
Tu parles d'une classe à rajouter par dessus PDO pour le rentre à peu prés utilisable, génial, alors puisqu'il y a des trucs qu'il faut rajouter de toute manière, pourquoi s'encombrer de PDO ?
De plus tu parle d'un session manager, et bien ce n'est pas le rôle 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'accéder à 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 problème de requête devrait être pris nativement en charge par PDO, ou n'importe quel autre mode de connexion.
Exact, entre beaucoup de systèmes, il y aura des différences. Mais PDO permet de mâcher une bonne partie du travail de base pour les language avec une syntaxe SQL.Citation:
Pour le sujet de la production d'un code universel, comme on l'a dit, le problème se situe bien en amont de PDO puisque les différents moteurs ne parlent pas la même langue.
Après, pour le --somme toute petit-- pourcentage restant, avec ou sans PDO, vous devrez traiter le cas manuellement de toute façon.
C'est peut-être le côté "pervers" de PDO : laisser croire que l'interopérabilité est possible. Mais pour du CRUD de base, il y a un intérêt certain à l'utiliser.Citation:
Envoyé par FMaz
Effectivement, beaucoup de gens semblent penser que toute requête imaginable sera fonctionnelle et traduite à 100%. Ce n'est malheureusement pas la réalité 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-même une classe pour s'en occuper automatiquement (ce qui devrait être interprété, donc plus lent que PDO qui est compilé nativement)
PDO automatise ce genre d'opération de base à très bas niveau. Pour moi (et je ne suis pas tous), c'est un des gros avantage de PDO.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Un autre autre avantage est la possibilité de pouvoir binder des valeurs, ca fait des requêtes plus propres. Certaines personnes pourraient dire que sprintf() peut aussi placer des valeurs dans la chaine, mais le problème 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 requête deviens un bloc de code bien défini.
Pour finir, je dirais qu'il fut un temps ou je détestais la POO. J'affirmais qu'avec une bonne organisation de fichier, et une bonne convention de nommage, s'était inutile. Je poussais même la critique en affirmant que vu qu'en procédurale pure, on ne segmentait pas tout le code en l'isolant dans des méthodes d'objets, on pouvais plus facilement optimiser ce code afin de grouper plusieurs actions en même temps.
Je pense toujours que j'ai partiellement raison. Cependant je pense que la POO apporte des avantages non-négligeable du point de vu de l'ergonomie, du contrôle d'accès (private, protected, public), et une foule d'autres petits avantages pas nécessairement nécéssaires, mais tout de même très apprécié et qui facilitent le développement.
PDO, c'est comme la POO: à strictement parler, c'est pas essentiel, mais quand on apprend à aimer toutes ces petites subtilités, on ne veux plus la laisser partir. (9 jours plus tôt 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:
Src.: http://www.slashon.com/index.php/200...-_Vous_adapterCitation:
Suppressions
Cette fois-ci, PHP6 fait le ménage en supprimant (pour ceux qui ne savent pas) : Les Register globals, Magic quotes, Safe Mode, PECL (qui pourra être téléchargé, mais absent dans le package officiel de PHP6).
Certaines extensions les moins utilisées migrent vers PECL mais aussi celles des bases de données laissant cette fois la place à PDO que nous introduirons plus tard...
src: http://manuel-esteban.com/?p=31Citation:
Dans cette nouvelle version de PHP, les fonctions telles que mysql_connect seront toutes déportées dans PECL (un dépôt d’extensions PHP non obligatoires) pour laisser la place à PDO. Ce changement majeur va forcer bon nombre de développeurs à se mettre à jour, et à ne plus utiliser les fonctions de mysql_* au profit de l’extension PDO.
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).
En même 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 même 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 rétrocompatiblité (sur une dizaine de sites de taille parfois importante que j'ai eu à migrer, aucun n'a pris plus d'une journée, et la moitié d'entre eux n'ont nécessité 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.
La portabilité se situe au niveau des fonctions d'accès, pas au niveau de la formation des requêtes SQL.Citation:
Envoyé par CinePhil
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 complété. Mais comme PDO est la direction dans laquelle PHP va évoluer, c'est un bon réflexe de l'utiliser afin que dans quelques années, 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
Moins que n'importe quel autre mécanisme d'abstraction des fonctions d'accès à la base de données, car c'est la seule extention qui est compilée nativement.Citation:
Envoyé par CinePhil
Après il faut comparer des pommes avec des pommes, et savoir relativiser les "moins performant".
Fabien potencier expliquait assez bien cette réalité lors d'une conférence 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.
Oui, c'est à mon avis la faiblesse #1 de PDO.Citation:
Envoyé par CinePhil
Ceci étant dis, dans quel cas est-ce nécéssaire d'avoir cette information ?
- Au moment de la création de la requête
--> Créée 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 déjà dis dans un autre sujet.
Ensuite lorsqu'on comprend bien le fonctionnement des placeholders, on comprend assez vite que d'avoir la sortie complète de la requête est inutile, puisque le bug ne proviendra pas de la valeur placée par le place holder. Certe, il faut faire confiance à PDO, et bien savoir ce que les différents PDO::PARAM_xxx font.
L'extrait de l'erreur lancé par mysql suffit généralement à remplir le trou d'information manquante s'il y en as un.
Et puis finalement, vous comparé l'exécution d'une requête simple avec une requête préparée. Avez-vous déjà fait des requêtes préparé avec mysql_ ou mysqli_ ?
... parceque query et exec en PDO retourne aussi le résultat complet, mais ce n'est pas des requête préparés.
Donc en somme, une partie du problème est que vous utilisé une autre facon de transiger avec MySQL. Une requête préparée se fait en 2 partie, et seul MySQL assemble les 2 résultats. Riens à voir avec PDO.
Encore une fois, comparez les pommes à des pommes.
Sans aucun doute. PDO vaux tout à fait la peine d'être appris malgré qu'il ne soit pas aussi intuitif au départ que mysql_ ou mysqli_ .Citation:
Envoyé par CinePhil
Le code sera plus propre, plus sécur, et normalisé.
Maintenant que je me suis fait un connexion manager et que j'ai développé mes classes étendu de PDO et PDOStatement et intégré une gestion automatisé des erreurs: je suis vraiment heureux, ma vie s'est grandement améliorée. PDO à même guérrit ma grippe.
Donc voilà, amusez-vous !
Citation:
Envoyé par Rakken
Probablement que les hébergeur vont offrir les 2 types d'hébergement: 5 ou 6.
mais beaucoup des fonctionnalité de PHP6 ont été, ou vont être prévu pour des version de php 5.x. Par exemple, php 5.3 propose beaucoup de fonctions qui étaient initialement prévu pour PHP6, et déjà 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 réputation d'être un language amateur. Il n'est pas toujours pris au sérieux pour les gros développement 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 à décidé 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 sérieux.
Donc c'est vrai que PHP6 ne sera pas aussi largement déployé que les versions précédentes 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 bâclée, ou d'un programmeur peu compétent.
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'avènement de normes plus stricte est pour moi un véritable soulagement.
Je ne comprends pas bien ce que tu dis.
Tu veux dire que les requêtes préparées avec mysqli ou avec PDO ne fonctionnement pas sur le meme principe ?
Ce que je dis, c'est que les gens comparent des requêtes directes (mysql_query) avec les requêtes préparés 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 requête préparé:
On envoi un "moule" de requête au serveur, qui la stock temporairement j'imagine (je connais pas les détails internes), puis dans un second temps, on envoi les paramètres et l'ordre dans lequel les placer les valeurs (dans les place holder), et d'exécuter la requête ainsi forgée.
Alors pour obtenir la requête complète et construite, il faudrait que MySQL retourne le résultat 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 débugger la requête qui se cache derrière la vue...
Edit:
En quoi ce code MySQLi permet-il d'avantage de débugger la valeur totale d'une requête que PDO ?:
Je ne vois pas plus comment vous arrivez à obtenir:Code:
2
3
4
5
6
Code:
2SELECT District FROM City WHERE Name='Amersfoort';
... et je me demande même au moins une personne sur la terre a déjà fait des prepared statement avec mysql_ tellement c'est manuel et pénible.
Oui donc mysqli et PDO pour les requêtes préparées c'est la même chose.Citation:
En quoi ce code MySQLi permet-il d'avantage de débugger la valeur totale d'une requête que PDO ?:
Exact.Citation:
Envoyé par sabotage
C'est pour cette raison que je trouvais les gens dur dans leurs critiques envers PDO, qui souffre exactement du même défaut que les autres.
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 même chose
Effectivement puisque je ne sais même pas si j'ais vu une seule fois ici "un vrais prépare 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 intéret :?
Oui tout est dans
Avant de poster j'ais recherché, il me semble que JulP a abordé le sujet :oops:Code:$dbd->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
À 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 suggéré", c'est pour prévenir le plus possible les injection SQL, tel que l'OWASP l'avait d'ailleurs suggéré.
Donc oui, très utile à savoir (même moi je l'ignorais), mais pas si "choquant", vu qu'au final ca ne change pas grand chose... même qu'un prepare pour une seule exécution, c'est plus lent qu'une requête direct... :roll:
avec PDO on peut créer notre propre pilote en PHP :ccool:
http://pecl.php.net/package/pdo_user
c'est ici que les constantes PDO::PARAM_EVT_* seront utilisées