Standardisation des accès aux SGBD via AdoDB

À l'instar d'autres langages et environnements de développement arrivés largement à maturité, PHP gagne aujourd'hui un réel intérêt grâce à de nombreuses bibliothèques de ce que l'on tend à appeler « composants », et parfois qualifiées de framework, middleware, ce qui nous évoquera sûrement quelque chose…

Dans la jungle de ces bibliothèques souvent distribuées gratuitement, il en est une incontournable.

Parce que l'accès aux bases de données via PHP n'est pas homogénéisé selon les SGBD accédés, il est nécessaire de connaître chaque fonction, chaque syntaxe de langage pour chacun de ces SGBD :

//Connexion à une base MySQL :
$link = mysql_connect("mysql_host", "mysql_user", "mysql_password");
mysql_select_db("your database", $link)

//Connexion à une base Interbase :
$link = ibase_connect($yourdb, $user, $password);

On voit pour ces connexions deux différences majeures :

1. Les fonctions appelées sont respectives au SGBD accédé ;
2. Pour MySQL, il est nécessaire d'appeler une fonction supplémentaire pour sélectionner la base de travail alors que pour Interbase, la connexion au serveur et l'accès à la base s'effectuent en une seule opération ibase_connect.

Le code ainsi créé sur un type de base n'est pas ou peu portable sur une autre base, ce qui peut entraîner la réécriture quasi complète d'un code écrit pour MySQL lors de son passage sur Interbase, par exemple.

AdoDB est un middleware d'accès aux bases de données qui vous évitera l'appréhension à changer de base - quand vous le souhaiterez - vers une autre base, souvent pour des raisons de performances, ou bien parce qu'un client souhaite intégrer votre produit dans son système d'information fonctionnant avec une autre base que celle pour laquelle votre produit a été conçu.

Par middleware, on entend couche intermédiaire de traitement. Ici il s'agira d'une bibliothèque donc les fonctions sont intercalées entre vous, le développeur, et les méthodes PHP classiques d'accès SGBD que vous connaissez. Pour vous connecter et manipuler vos SGBD, vous appellerez des méthodes uniques d'AdoDB quel que soit le type de base. Ce sera le rôle d'AdoDB de rentrer dans le spécifique en traduisant ce que vous lui avez demandé dans le langage compris par le type de SGBD.

Voici les systèmes supportés par AdoDB :

• MySQL
• Oracle
• SQL Server
• Sybase
• Sybase SQL Anywhere
• Informix
• PostgreSQL
• FrontBase
• Interbase (& Firebird)
• Foxpro
• Access
• Supporte également ADO & ODBC.

Dans cet article, nous nous intéresserons à trois bases de données très différentes : Microsoft Access, MySQL & Borland Interbase 6.

Nous verrons, facilement, comment passer de l'une à l'autre en utilisant – fonction pour fonction – le même code !

AdoDB mérite réellement un approfondissement de ses fonctionnalités (gestion des sessions, présentation des données…) qui dépassent le cadre de cette introduction. Nous verrons ici comment se connecter aux bases de données et comment faire un simple select sur une table…

II-A. Configuration utilisée pour cet article▲

II-B. Se procurer AdoDB▲

Procurez-vous AdoDB à l'adresse : http://adodb.sourceforge.net/

AdoDB est à l'heure actuelle dans sa version 4.98 et en continuelle évolution, grâce à une communauté active.

Une fois AdoDB téléchargé, décompressez l'archive sous le root de votre serveur web. Il sera nécessaire d'inclure un script, aussi veillez à ce que le répertoire AdoDB soit accessible.

Ici, l'ensemble des éléments sont placés dans le même dossier. Nous aurons besoin également de trois bases de données identiques, que nous nommerons de manière triviale « MYBASE ».

II-C. Structure des différentes bases de données▲

Une simple table « MEMBER » contenant deux champs (ID_MEMBER et PSEUDO) typés entier et caractères suffira à notre exemple. Il vous suffit de créer cette table dans les différents SGBD avec lesquels vous souhaitez suivre la démo.

Exemple sous MySQL via PhpMyAdmin :

II-D. scripts▲

Nous utiliserons un seul script pour accéder aux trois bases.

Un formulaire permettant de sélectionner notre base renverra la variable $database à un script de traitement (cf. balise <form… : getdatas.php).

Un formulaire HTML avec un simple <select> sera amplement suffisant.

<form method="post" action="getdatas.php">
    <select name="database">
        <option value="interbase" selected>via interbase</option>
        <option value="mysql">via mysql</option>
    <option value="access">via access</option>
   </select>
    <input type="submit" name="Submit" value="interroger"/>
</form>

Nous appellerons le script getdatas.php qui contiendra notre code.

Point n'est besoin de commenter plus avant ce formulaire.

<?php
include('_AdoDB/adodb.inc.php');
switch ($database){
case 'interbase':
    $conn = &ADONewConnection('ibase');
    $conn->PConnect('127.0.0.1:C:\DEV-TESTS\DB_Portable\MYBASE.GDB',
    'SYSDBA','masterkey', "");
break;
case 'mysql':
    $conn = &ADONewConnection('mysql');
    $conn->PConnect('localhost','','','mybase');
break;
case 'access':
    $conn = &ADONewConnection('access');
    $conn->PConnect('MSACC');
    # utilisation du DSN, déclaré dans le panneau de configuration
break;
}

Dans un premier temps, nous avons inclus le script général d'AdoDB, qui va nous permettre de créer un nouvel objet 'ADONewConnection' auquel nous passons en paramètre le nom du SGBD que nous voulons utiliser.

Dans un second temps, nous allons ouvrir une connexion en fonction de la base en utilisant la fonction Pconnect(), fonction accessible après la construction de l'objet $conn. Ici on voit que les paramètres attendus pour la connexion diffèrent en fonction de la base de données.

Là où Interbase demande un chemin IP :PATH, AdoDB se contente du DSN pour Access, mais la fonction reste la même. Rappelez-vous que pour MySQL, se connecter et sélectionner une base nécessitait deux appels de fonctions.

En quelques lignes de code, nous avons déjà créé un objet nous permettant un accès standard, quel que soit le SGBD. Dès à présent, toutes les instructions que nous appellerons seront « compatibles ».

if (isset($database)){
    $recordSet = &$conn->Execute('SELECT * FROM MEMBER');
    if (!$recordSet)
        echo $conn->ErrorMsg();
    else
    while (!$recordSet->EOF) {
    echo $recordSet->fields[0].' '.$recordSet->fields[1].'<BR>';
    $recordSet->MoveNext();
    }
$recordSet->Close(); // optionnel
$conn->Close(); // optionnel
} else {
   echo 'vous devez spécifier une base de données !';
}
?>

Tout d'abord, nous vérifions que $database est bien connu de notre script afin d'éviter toute erreur. Grâce à l'instruction $conn->Execute, nous passons en paramètre notre requête SQL.

AdoDB se chargera d'interroger la base et de placer le résultat de cette requête dans un attribut de type tableau, accessible sous le nom 'fields' dans l'objet $recordset.

Les instructions EOF & MoveNext() nous permettent de nous déplacer dans la collection de résultats renvoyés.

Ainsi, chaque SGBD nous renverra le contenu de sa table « member » en utilisant un code source commun.

Quelle que soit la base de données interrogée (si le contenu est identique), l'affichage obtenu sera :

Bien évidemment, nous n'avons vu ici qu'une simplissime introduction à l'écriture de scripts « portables ». AdoDB regorge de fonctionnalités nécessaires à la bonne exploitation d'une base de données. Par exemple, vous serez probablement intéressés par les fonctionnalités de mise en cache des requêtes SQL exécutées par AdoDB…

Par des fonctions accessibles par les objets que nous avons créés, il est possible d'obtenir des informations sur les champs (avec FetchFields()), d'obtenir le nombre d'enregistrements retournés (avec RecordCount())… Vous trouverez sur le site d'AdoDB une traduction française des principales fonctions et leur description.

Au-delà de la portabilité du code produit avec AdoDB, il faut souligner le gain de temps, non négligeable, qu'elle vous fera gagner. D'autre part, la « maintenabilité » de votre code dépasse de loin ce qu'elle était…

Personnellement, la migration d'une application PHP d'une base vers une autre représentait un vrai challenge… Aujourd'hui, nonobstant des particularités telles que les procédures stockées, les triggers, les generators (ça fait beaucoup…) qui ne sont pas supportés par toutes les bases (il faut dire aussi que ce sont des traitements complexes propres au serveur et non relevables par un middleware à hautes performances), il est possible de construire un code 100 % portable.

Cependant, la portabilité entre SGBD-R réellement dignes de ce nom (d'interbase vers SQL Server, de SQL Server vers Oracle, etc.) est, avec un minimum d'efforts, assurée par cette bibliothèque.

Pour toutes informations, corrections à ajouter à cette introduction, contactez-moi :

Fabien Fouret.

Développeur / Formateur