Ê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.
Avec PDO, doit-on tout de meme mettre des mysql_real_escape
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.
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.
Vous devez donc injecter les valeurs de façon traditionnelle directement dans la string qui contient votre moule de requête:
$query = 'SELECT * FROM aaa WHERE id=? LIMIT ' . (int)$from . ',' . (int)$length . ';';
>> Pas de fonction *_num_rows()
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.
Partager