Cours Bases de données PDO SQLite Mysqli (Intermédiaire)

Base de données : PDO, SQLite, MySQLi — points essentiels. PDO (PHP Data Objects), SQLite et MySQLi sont des interfaces PHP pour accéder et manipuler des bases de données : PDO fournit une couche d'abstraction orientée objet, SQLite est un moteur embarqué stocké dans un fichier unique, et MySQLi cible MySQL.

🎯 Ce que vous allez apprendre

• Activation et configuration — activer l'extension et les drivers dans php.ini (ex. php_pdo_mysql.dll, php_pdo_sqlite.dll) et diagnostiquer les erreurs d'extension.
• Connexions et gestion d'erreurs — créer une instance de PDO, gérer PDOException et utiliser les options (attributs, connexions persistantes) pour des connexions robustes.

L'abstraction de données avec PDO

La couche d'abstraction sépare la logique d'accès des spécificités du moteur, facilitant la réutilisation du code, la gestion des transactions et des exceptions au niveau applicatif. Cette approche réduit les adaptations nécessaires lors d'un changement de SGBD et clarifie les tests unitaires et la maintenance.

• Transactions ACID — beginTransaction(), commit(), rollBack() ; attention au comportement selon le driver et au mode auto-commit.
• Requêtes préparées — usage de prepare(), bindParam(), execute() pour réutiliser des statements et limiter les risques d'injection.
• Récupération des résultats — modes PDO::FETCH_ASSOC, PDO::FETCH_OBJ, PDO::FETCH_NUM ; impact sur mémoire et gestion du curseur (closeCursor()).
• SQLite — fonctionnement embarqué, typage souple, création de fichier-base et contraintes de concurrence pour petites applications.
• MySQLi — styles procédural et objet pour accès natif à MySQL et optimisations spécifiques.

📑 Sommaire du document

• Activation et configuration des extensions
• Connexions PDO : gestion d'erreurs et options
• Transactions et gestion des exceptions
• Requêtes préparées et prévention des injections
• Récupération des résultats et optimisation mémoire
• SQLite : usage embarqué et gestion des fichiers
• MySQLi : accès natif et performances
• Comparatif et migration depuis l'extension mysql_

Configuration de l'environnement PHP pour les bases de données

Vérifier la présence et la configuration des extensions est nécessaire avant le déploiement. Activer pdo, pdo_mysql et/ou pdo_sqlite dans le fichier php.ini, contrôler les chemins vers les DLL/so, et configurer le journal d'erreurs pour faciliter le diagnostic. Sur les environnements mutualisés, valider avec phpinfo() la disponibilité des drivers et adapter la configuration d'encodage (UTF-8) et de timezone pour éviter des incohérences lors des import/exports de données.

Prérequis techniques

Les prérequis ci‑dessous visent à garantir compatibilité, sécurité et performances pour l'utilisation conjointe de PDO, SQLite et MySQLi dans des projets intermédiaires.

• PHP : recommandé PHP 8.0 ou supérieur pour disposer des correctifs de sécurité et des améliorations de performances ; compatible avec PHP 7.4 si nécessité de rétrocompatibilité, mais privilégier les versions maintenues.
• Extensions : activer pdo, pdo_mysql pour MySQL et pdo_sqlite ou sqlite3 pour SQLite.
• Drivers et client MySQL : disposer d'une version cliente MySQL compatible (MySQL/MariaDB) et d'un accès aux paramètres php.ini si des modules doivent être ajoutés.
• Permissions : droits d'écriture appropriés pour les fichiers SQLite et configuration sécurisée des comptes de base de données pour les connexions distantes.

Comparatif : PDO vs MySQLi vs Ancienne extension

Le tableau ci-dessous synthétise les différences d'usage et d'objectif. PDO privilégie la portabilité entre SGBD et une API orientée objet unique. MySQLi apporte des optimisations et des fonctionnalités propres à MySQL. L'ancienne extension mysql_ est obsolète et non sécurisée ; la migration vers PDO ou MySQLi est recommandée pour des raisons de maintenance et de sécurité.

Flexibilité des drivers : PDO supporte de multiples pilotes (par ex. pdo_mysql, pdo_sqlite, pdo_pgsql) et offre des adaptateurs pour des bases indiciées comme SQL Server via pdo_sqlsrv ou des implémentations tierces telles que pdo_dblib. Cette variété facilite la migration entre SGBD sans réécrire l'accès applicatif, tout en imposant de vérifier les spécificités et limitations de chaque driver lors du déploiement.

PDO : Abstraction ou Driver natif ?

PDO est une couche d'abstraction : elle définit une API uniforme permettant d'exécuter des requêtes, préparer des statements et gérer les transactions sans exposer l'implémentation interne du driver. PDO ne réécrit pas le moteur de base de données ni ne remplace un driver natif : chaque appel PDO est transmis au driver PDO spécifique qui traduit les opérations pour le SGBD cible. Cette séparation signifie que certains comportements (gestion des types, prise en charge des transactions, performances de locks) restent dépendants du driver PDO utilisé et du SGBD. Lors d'une migration, tester les scénarios critiques (verrous, transactions longues, encodages) permet d'anticiper les ajustements nécessaires au niveau du driver.

Gestion des procédures stockées

Le support des procédures stockées varie selon l'API et le SGBD. MySQLi expose des mécanismes natifs pour appeler des procédures, récupérer plusieurs jeux de résultats et utiliser bind_result ou store_result(). PDO permet d'appeler des procédures via des requêtes préparées (par ex. CALL proc_name(?, ?)) et de lier les paramètres comme pour une requête normale ; toutefois, la gestion multi-jeux de résultats et certains types OUT/INOUT peuvent demander des étapes supplémentaires (utilisation de PDOStatement::nextRowset(), adaptation du driver). En pratique, choisir MySQLi pour des usages intensifs et spécifiques de procédures MySQL peut simplifier l'intégration, tandis que PDO garde l'avantage de la portabilité si les procédures sont standardisées entre environnements.

• Drivers supportés par PDO :
  • MySQL (via pdo_mysql)
  • PostgreSQL (via pdo_pgsql)
  • SQLite (via pdo_sqlite)
  • SQL Server (via pdo_sqlsrv)
• Ces éléments sont utiles dans un tutoriel PHP PDO afin de choisir le bon driver selon l'environnement de déploiement.

Sécuriser ses requêtes avec PDO

La sécurité repose sur l'utilisation systématique de statements préparés et la liaison de paramètres. Un tutoriel PHP PDO doit insister sur la validation des entrées, la préparation des requêtes et la gestion stricte des erreurs. Les requêtes préparées PHP réduisent les risques liés à la construction dynamique de SQL et améliorent la résistance contre la plupart des attaques par injection.

Exemple de code : Connexion PDO

Exemple minimal et sûr de connexion avec gestion d'exceptions et options courantes. Adaptez le DSN, l'utilisateur et le mot de passe selon votre environnement. Le bloc montre aussi l'activation du mode d'erreur par exception et un réglage d'encodage.

 PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
    PDO::ATTR_PERSISTENT => false,
];

try {
    $pdo = new PDO($dsn, $user, $pass, $options);
} catch (PDOException $e) {
    // Gestion d'erreur claire et non verbeuse pour la production
    error_log($e->getMessage());
    throw $e;
}
?>

Pourquoi migrer de l'extension mysql_ vers PDO ?

L'extension mysql_ est obsolète et ne supporte pas les fonctionnalités modernes nécessaires pour une application sécurisée et maintenable : absence de requêtes préparées natives, API procédurale limitée, et manque de portabilité entre SGBD. Migrer vers PDO permet de standardiser la connexion base de données PHP et d'utiliser des requêtes préparées PHP pour réduire les risques. Des exemples concrets et des patterns de migration réduisent le code spécifique au moteur et facilitent la maintenance.

Sécurité : Pourquoi éviter l'extension mysql_

L'ancienne extension oblige souvent à concaténer des chaînes pour construire des requêtes, ce qui expose directement aux injections SQL. Les requêtes préparées, la liaison strictement typée des paramètres et la gestion d'erreurs par exceptions sont des protections de premier ordre. Compléter par une validation côté application, l'utilisation de transactions lorsque c'est possible et la journalisation d'opérations critiques renforce la robustesse. En environnement où un driver ne gère pas les transactions, prévoir des mécanismes applicatifs compensatoires (verrouillage logique, idempotence des opérations).

💡 Pourquoi choisir ce cours ?

Support dense en extraits de code et cas pratiques, focalisé sur l'usage effectif de l'abstraction et la configuration concrète dans php.ini. Les auteurs J‑F Dazy et J‑F Berger signent ce cours et privilégient une approche pragmatique : diagnostics, bonnes pratiques et exemples réutilisables pour des projets PHP backend. Le contenu est aligné sur la documentation PHP officielle et structuré autour de tests simples et réplicables sur environnements PHP 7.4 et supérieurs.

👤 À qui s'adresse ce cours ?

• Public cible : développeurs PHP backend et étudiants en développement web souhaitant améliorer portabilité, sécurité et gestion des transactions pour des applications légères à moyennes.
• Prérequis : connaissances de base en PHP orienté objet et SQL (SELECT/INSERT/UPDATE/DELETE) ; accès pour modifier php.ini ou installer des extensions ; notions élémentaires de permissions fichiers pour SQLite.

❓ Foire Aux Questions (FAQ)

Comment PDO gère-t-il les transactions et que se passe-t-il si le driver ne les supporte pas ?

• PDO expose beginTransaction(), commit() et rollBack() pour piloter les transactions et respecter les propriétés ACID lorsque le SGBD les implémente.
• Si un driver ne supporte pas les transactions, une exception est généralement levée : prévoir une stratégie d'appoint (verrouillage applicatif, journalisation des opérations, ou designs idempotents).

Quels bénéfices concrets des requêtes préparées par rapport à PDO::query() ?

• Les requêtes préparées dissocient l'analyse/compilation du plan d'exécution et la fourniture des paramètres, réduisant le coût pour exécutions répétées.
• La liaison de paramètres élimine la plupart des risques d'injection SQL ; pour approfondir, consultez le Cours PHP avancé : Gérer une DB avec PDO ou le Cours Bases de données en PDF.

Exemples de cas d'usage

• Application multi-base — contexte : besoin de connecter la même logique métier à MySQL en production et SQLite en local pour les tests. Avantages : PDO permet d'isoler la couche d'accès et de réutiliser la même API. Attention : tester les différences de comportements (transactions, encodage, fonctions SQL spécifiques).
• Projet MySQL dédié — contexte : application à fort trafic exploitant des procédures stockées et des optimisations MySQL. Avantages : MySQLi peut offrir des optimisations natives et un contrôle fin des procédures ; utiliser MySQLi si des fonctionnalités spécifiques au moteur sont massivement exploitées.
• Prototype rapide / embarqué — contexte : outil ou POC devant stocker localement les données sans serveur. Avantages : SQLite (via PDO ou sqlite3) simplifie le déploiement et les tests unitaires, avec des contraintes de concurrence à surveiller pour la montée en charge.