Discussion :

[Christophe]

Bonjour,

Je vais avoir un petit projet PHP à faire. J'ai déjà fait un peu de PHP mais il y a un moment, à l'époque de mysql_connect et cie.

Comme je sais que mysql_connect est déprécié, je dois me tourner vers PDO ou MySQLI. Lequel me conseilleriez-vous ? (avantages/inconvénients des deux).

Et du coup, ou faut-il faire gaffe niveau sécurité ? (injection SQL, protections des variables de session).

Merci pour vos retours.

[Celira]

En mon sens, mysqli existe essentiellement pour remplacer l'api mysql dans des applis existantes. Donc si tu démarres une nouvelle application, mieux vaut utiliser directement PDO.
Je trouve la structure des fonctions et surtout le passage de paramètres aux requêtes préparées beaucoup plus intuitif avec PDO qu'avec mysqli : le fait de pouvoir envoyer un tableau de paramètres à la fonction execute sans passer par trouze-mille fonctions bindParam ou bindValue est hautement appréciable.

Au niveau sécurité et notamment injections SQL, le principe de base reste valable : on ne met jamais des valeurs en provenance de l'extérieur directement dans une requête.
Avec mysqli, il ya la fonction mysqli_real_escape_string, équivalent de mysql_escape_string. Mais surtout il y a les requêtes préparées : tu mets des marque-places à la place des valeurs de paramètres, tu passes les paramètres à l'exécution et pouf! PDO (ou mysqli) se charge de faire les échappements pour toi.

Evidemment, le but originel des requêtes préparées est de pouvoir ré-exécuter la même requête avec des valeurs différentes (très pratique pour les insertions en masses), mais ça sert beaucoup pour gérer les échappements.

A lire sur le sujet : Comprendre PDO, avec de jolis extraits de code qui compare l'ancienne syntaxe mysql, PDO et mysqli.

[andry.aime]

Pour la comparaison de fonctionnalité, tu peux voir ici: http://php.net/manual/fr/mysqlinfo.api.choosing.php

A+.

[ABCIWEB]

Salut,

Je confirme tous les points évoqués par Celira en ajoutant qu'en plus d'être beaucoup plus pratique - la possibilité de passer un tableau dans la fonction execute() est un avantage considérable - PDO est aussi beaucoup plus agréable à écrire : fini les noms de fonctions à rallonge. Donc y'a pas vraiment de question à se poser, mysqli est pratique pour mettre à jour un ancien site, mais pour les nouveaux c'est PDO sans hésitation. Plus facile aussi pour changer de sgbdd si besoin et tous les nouveaux exemples de codes sur le web sont maintenant écrits avec PDO donc bon y'a pas photo. Niveau expérience, j'ai utilisé les deux et jamais je ne reviendrai vers mysli tant que j'ai le choix.

[Celira]

Plus facile aussi pour changer de sgbdd si besoin

à condition de ne pas utiliser de syntaxe spécifique dans les requêtes.

[ABCIWEB]

à condition de ne pas utiliser de syntaxe spécifique dans les requêtes.

Dans ce cas effectivement le code sera entièrement compatible sans besoin de faire quasiment aucune modification. Mais même sans cette condition, il n'y aurait que ces requêtes spécifiques à réécrire, alors qu'avec mysqli il faudrait réécrire tout le code. Pour dire que dans tous les cas PDO facilite les migrations

[Tsilefy]

Pour ajouter à ce qui a déà été dit:
- PDO permet d'utiliser des paramètres nommées à la place du placeholder "?"
- PDO permet de récupérer les résultats sous différents formats avec fetchAll: tableau indexé, tableau assocatif, colonne, objet, groupés par un champ, ou même filtrés par une fonction.
- et le plus important: PDO est devenu une sorte de standard adopté par défaut par la communauté. Après des années à parcourir github, je ne me souviens pas d'un seul repository qui utilise mysqli. Bien sûr qu'il y en a, mais la quantité est rès inférieure à PDO.

[Christophe]

Merci à tous pour vos retours. Je vais jeter un oeil à tout ça.

[Christophe]

J'ai parcouru en diagonale le tuto indiqué. Explicite.

Si j'ai bien compris, en faisant une requête préparée, l’échappement se fait tout seul et me protège des injections SQL, ce qui n'est pas le cas avec une requête de type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$query = 'SELECT * FROM foo WHERE bar=1;';
$arr = $pdo->query($query)->fetch();

c'est bien ça ?

[sabotage]

Avec une préparation, il n'y a pas d'echappement. Les paramètres sont traités indépendamment de la requête.

[ABCIWEB]

Cela dit les injections sql ne sont possibles que si la requête contient des variables utilisateur. Dans ton exemple ce n'est pas les cas et de plus elle ne nécessite pas d'échappement donc elle est correcte (et sécurisée) en l'état.

Au besoin il y a la fonction quote de pdo pour échapper des variables dans des requêtes non préparées. On s'en sert aujourd'hui très peu étant donné que, comme l'indique le manuel, le système de cache permet un temps d'exécution plus rapide avec des requêtes préparées dès que la requête dépend d'une variable.

Il y a quelques années le bilan était moins favorable en terme de rapidité si bien qu'on pouvait trouver un intérêt à n'utiliser les requêtes préparées que pour celles incluant des entrées utilisateur (pour un gain en sécurité) et les requêtes multiples (pour un gain en rapidité).

Aujourd'hui en pratique l'utilisation des requêtes préparées s'est généralisée à toutes les requêtes incluant des variables. Cela permet d'uniformiser la syntaxe en même temps que d'offrir systématiquement un maximum de sécurité.