Pour les templates, pas de problème, gettext est là pour ça (je reviendrais peut-être dessus dans un futur article, si je suis motivé). Si vous n’avez pas envie de mettre les mains dans le système, votre framework propose sûrement une émulation plus ou moins performante en pur PHP, ou, au pire, une solution “maison”. Bref, ça c’est facile.

Ce qui pose plus de problèmes, ce sont les données présentes en base. Par exemple : la liste de catégories pour les tickets d’incidents des clients. Elle est stockée en base dans une table qui contient notamment l’intitulé de cette catégorie. Oui, mais cet intitulé doit être traduit. Et comme les catégories sont gérées dynamiquement, ce n’est pas envisage d’utiliser la méthode gettext qui repose sur des fichiers statiques.

Transformer le modèle

Nous allons commencer par ajouter une table pour stocker les traductions. Si on envisage la catégorie comme un élément identifié par un id uniquement, les traductions sont liées à une catégorie par une relation “1-N” : 1 catégorie possède N traductions. Chaque traduction est identifiée par un code de langue. L’idée est de retirer les champs contenant du texte à traduire de la catégorie, et de les stocker dans la table contenant les traductions

Schéma de la base

On crée donc les tables suivantes :

CREATE TABLE `category` (
	`id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
	`created_at` DATETIME NOT NULL,
	`deleted_at` DATETIME NULL,
	PRIMARY KEY (`id`)
) ENGINE = InnoDB;

CREATE TABLE `category_i18n` (
	`category_id` INT UNSIGNED NOT NULL,
	`lang` VARCHAR(6) NOT NULL,
	`name` VARCHAR(45) NOT NULL,
	PRIMARY KEY (`lang`, `category_id`),
	INDEX `category_i18n_category_fk` (`category_id` ASC),
	CONSTRAINT `category_i18n_category_fk`
		FOREIGN KEY (`category_id` )
		REFERENCES `category` (`id` )
		ON DELETE CASCADE
) ENGINE = InnoDB;

Insertion

Lors de l’insertion, il faut d’abord insérer dans category, récupérer l’id puis insérer dans category_i18n. Puisqu’on travaille avec plusieurs tables en même temps, l’utilisation d’une transaction (avec le moteur de stockage InnoDB) est fortement recommandée.

mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO category (created_at) VALUES (SYSDATE());
Query OK, 1 row affected (0.00 sec)

mysql> SET @category_id = LAST_INSERT_ID();
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO category_i18n (category_id, lang, name) VALUES
    -> (@category_id, 'fr', 'Incident réseau'),
    -> (@category_id, 'en', 'The network is fucked up');
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> COMMIT;
Query OK, 0 rows affected (0.00 sec)

Et ça donne :

mysql> SELECT * FROM category;
+----+---------------------+------------+
| id | created_at          | deleted_at |
+----+---------------------+------------+
|  3 | 2009-03-06 15:58:44 | NULL       |
+----+---------------------+------------+
1 row in set (0.00 sec)

mysql> SELECT * FROM category_i18n;
+-------------+------+--------------------------+
| category_id | lang | name                     |
+-------------+------+--------------------------+
|           3 | en   | The network is fucked up |
|           3 | fr   | Incident réseau          |
+-------------+------+--------------------------+
2 rows in set (0.00 sec)

Exemple d’implémentation en utilisant PDO

// $names contient un tableau associatif "langue => valeur"
function newCategory($dbh, $names = array())
{
	if ( empty($names) )
		return false;

	try {
		$dbh->beginTransaction();

		$sql =
			'INSERT INTO category
			(created_at)
			VALUES (SYSDATE())';

		$dbh->exec($sql);
		$id = $dbh->lastInsertId();

		$sql = array();
		foreach ( $names as $lang => $name ) {
			$sql[] = sprintf(
				'(%d, %s, %s)',
				$id,
				$dbh->quote($lang),
				$dbh->quote($name)
			);
		}
		$sql =
			'INSERT INTO category_i18n
			(category_id, lang, name)
			VALUES '.implode(', ',$sql);
		$dbh->exec($sql);

		$dbh->commit();
	} catch (Exception $e) {
		$dbh->rollback();
		throw $e;
	}
}

// appel de la fonction
$dbh = new PDO('mysql:host=localhost;dbname=test', 'test', 'test');
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

newCategory($dbh, array(
	'fr' => 'Incident réseau',
	'en' => 'The network is fucked up'
));
newCategory($dbh, array(
	'fr' => 'Incident système',
	'en' => 'The system screwed up'
));
newCategory($dbh, array(
	'fr' => 'Commande de matériel',
	'en' => 'I need some stuffs'
));
newCategory($dbh, array(
	'fr' => 'Problème typiquement français'
));

Sélection

Pour récupérer la liste des catégories, il faut savoir dans quelle langue on les veut. Pour cela, on peut se baser sur les préférences indiquée par le navigateur de l’utilisateur, ou sur ses options s’il est inscrit, etc. La requête de sélection se fait ensuite par une simple jointure.

Dans l’exemple suivant, on sélectionne d’abord les catégories en français et ensuite les catégories en anglais. La catégorie non-traduite n’apparaît pas. On pourrait utiliser un LEFT JOIN pour avoir un libellé NULL (ça peut servir dans certains cas).

mysql> SELECT c.id, ci.name
    -> FROM category c
    -> JOIN category_i18n ci ON (ci.category_id = c.id AND ci.lang = "fr")
    -> WHERE c.deleted_at IS NULL;
+----+-------------------------------+
| id | name                          |
+----+-------------------------------+
|  1 | Incident réseau               |
|  2 | Incident système              |
|  3 | Commande de matériel          |
|  4 | Problème typiquement français |
+----+-------------------------------+
4 rows in set (0.00 sec)

mysql> SELECT c.id, ci.name
    -> FROM category c
    -> JOIN category_i18n ci ON (ci.category_id = c.id AND ci.lang = "en")
    -> WHERE c.deleted_at IS NULL;
+----+--------------------------+
| id | name                     |
+----+--------------------------+
|  1 | The network is fucked up |
|  2 | The system screwed up    |
|  3 | I need some stuffs       |
+----+--------------------------+
3 rows in set (0.00 sec)

mysql> SELECT c.id, ci.name
    -> FROM category c
    -> LEFT JOIN category_i18n ci ON (ci.category_id = c.id AND ci.lang = "en")
    -> WHERE c.deleted_at IS NULL;
+----+--------------------------+
| id | name                     |
+----+--------------------------+
|  1 | The network is fucked up |
|  2 | The system screwed up    |
|  3 | I need some stuffs       |
|  4 | NULL                     |
+----+--------------------------+
4 rows in set (0.00 sec)

Modification

La modification peut être triviale, ou un petit peu complexe, selon le type d’interface utilisateur mise en place. Quelques astuces : si un simple UPDATE ne suffit pas, vous devriez regarder du côté de INSERT ... ON DUPLICATE KEY UPDATE ..., ou implémenter une suppression complète immédiatement suivi de nouvelles insertions (toujours avec une transaction).

Suppression

Grâce à la clause ON DELETE CASCADE il suffit de supprimer l’entrée dans catégorie pour que les traductions correspondantes soient également supprimées. Personnellement j’utilise le champ deleted_at pour effectuer une suppression logique et ne pas casser toutes les clés étrangères des tables qui font référence à la catégorie supprimée.

Pour utiliser un modificateur, il suffit d’effectuer un “ou” binaire, par exemple :

$results->fetchAll(PDO::FETCH_TRUC | PDO::FETCH_BIDULE | PDO::FETCH_CHOUETTE);

La plupart de ces modes ne fonctionnent pas lorsqu’ils sont définis par la méthode setFetchMode. Ça ressemble a un bug, mais vu que rien n’est documenté, c’est peut-être normal…

FETCH_CLASSTYPE

Ce mode est destiné à être utilisé conjointement avec FETCH_CLASS. Lorsqu’il est présent, la première colonne de la requête SQL indique le nom de la classe à utiliser.

Exemple :

class MyClass1 { }
class MyClass2 { }
$sql = 'SELECT CONCAT("MyClass",id), id, login FROM user LIMIT 0,2';
$results->fetchAll(PDO::FETCH_CLASS | PDO::FETCH_CLASSTYPE);

Array
(
  [0] => MyClass1 Object
    (
      [id] => 1
      [login] => sload
    )

  [1] => MyClass2 Object
    (
      [id] => 2
      [login] => js
    )

)

Si une classe n’existe pas, stdClass est utilisé (comme FETCH_OBJ).

Je suis vraiment curieux de savoir à quoi ce mode peut bien servir !

FETCH_GROUP

Ce mode est plutôt intéressant : il permet de regrouper les résultats selon la valeur de la première colonne de la requête. Il ne fonctionne qu’avec fetchAll.

Exemple, avec FETCH_ASSOC :

$sql = 'SELECT hash_algo, id, login FROM user LIMIT 0,4';
$results->fetchAll(PDO::FETCH_ASSOC | PDO::FETCH_GROUP);

Array
(
  [sha1] => Array
    (
      [0] => Array
        (
          [id] => 1
          [login] => toto
        )

    )

  [md5] => Array
    (
      [0] => Array
        (
          [id] => 2
          [login] => titi
        )

      [1] => Array
        (
          [id] => 3
          [login] => tata
        )

      [2] => Array
        (
          [id] => 4
          [login] => tutu
        )
    )
)

FETCH_UNIQUE

Ce mode retourne les résultats indexés selon la valeur de la première colonne de la requête. Outre l’aspect “suppression des doublons” (qui est une conséquence naturellement de l’indexation), ce mode est intéressant car il retourne un tableau associatif.

Par exemple, avec FETCH_ASSOC, ce mode permet d’obtenir directement les utilisateurs indexés par leur id :

$sql = 'SELECT id, login, email FROM user LIMIT 0,2';
print_r($results->fetchAll(PDO::FETCH_ASSOC | PDO::FETCH_UNIQUE));

Array
(
  [1] => Array
    (
      [login] => toto
      [email] => toto@foo
    )

  [2] => Array
    (
      [login] => titi
      [email] => titi@foo
    )
)

Et comme ce mode utilise moins de mémoire, il est un peu plus rapide que FETCH_ASSOC seul quand il n’y a pas de doublons.

FETCH_SERIALIZE

Pour l’instant je n’ai pas réussi à obtenir de ce mode autre chose que des messages du genre : SQLSTATE[HY000]: General error: PDO::FETCH_SERIALIZE can only be used together with PDO::FETCH_CLASS ou SQLSTATE[HY000]: General error: cannot unserialize class. J’ai donc ouvert un bug (#42916).

FETCH_PROPS_LATE

Ce mode est destiné à être utilisé conjointement avec FETCH_CLASS pour que les propriétés de la classe soient écrites *après* l’appel du constructeur.

Et voila, c’est la fin de la série d’articles sur les fetch modes de PDO… Tout feedback est le bienvenue ! Et maintenant il est temps d’optimiser ses scripts PHP :-)

FETCH_LAZY

Il se comporte comme un mélange de FETCH_OBJ et FETCH_ASSOC puisque l’objet retourné peut être accédé comme un objet ($r->id) ou comme un tableau associatif ($r['id']). Mais, comme son nom l’indique, il semble faire des bidouilles interressantes au niveau de la gestion de la mémoire ; d’après la documentation de PHP PDO::FETCH_LAZY crée les noms des variables de l’objet comme ils sont rencontrés.

A noter que ce mode ne peut-être utilisé qu’avec fetch, sans doute en raison de la gestion de la mémoire. De plus, le resultat affiché avec print_r ne semble par correspondre puisqu’on obtient :

PDORow Object
(
  [queryString] => SELECT id, login FROM user LIMIT 0,2
  [id] => 1
  [login] => toto
)
PDORow Object
(
  [queryString] => SELECT id, login FROM user LIMIT 0,2
  [id] => 2
  [login] => titi
)

Les performances par rapport à FETCH_BOTH sont étonnament bonnes (en comparant avec while + fetch) :

• Temps de récupération : -18,9%
• Taille du résultat : -77,8%

Toutefois, ces résultats doivent être considérés avec précaution : puisque ce mode n’utilise pas la mémoire de la même façon que les autres, mon script de test ne donne pas forcement des résultats pertinants. En pratique, sur une application réelle, pour afficher une liste d’éléments par exemple, en utilisant FETCH_LAZY plutôt que FETCH_ASSOC, le gain de mémoire est minime (de l’ordre de 0,05Ko, certes c’est toujours bon à prendre) et je n’observe pas de gain de vitesse significatif.

Pour l’instant, j’utilise ce mode quand les résultats ne vont pas être utilisés immédiatement, par exemple dans le cadre d’une architecture MVC où la requête est effetuée dans le modèle (ou dans le controlleur) et les résultats ne sont récupérés et affichés que plus tard dans la vue.

FETCH_COLUMN

Ce mode permet de récupérer uniquement une colonne, en précisant son numéro. Il fonctionne avec setFechMode, fetchAll et même directement query. Il fonctionne également avec fetch, mais il n’est pas possible de préciser le numéro de la colonne à récupérer (défaut 0). Les colonnes sont numérotées à partir de 0.

Attention, lorsque vous utilisez setFetchMode pour préciser le mode, il n’y a pas de valeur par défaut pour le numéro de colonne. Donc si le deuxième paramètre est absent, PDO retourne au mode par défaut FETCH_BOTH.

Exemple :

$results->fetchAll(PDO::FETCH_COLUMN, 1) // colonne 1 = le login

Array
(
  [0] => toto
  [1] => titi
)

Par rapport à FETCH_BOTH :

• Temps de récupération : -18,8%
• Taille du résultat : Non significatif (une seule colonne retournée)

Selon moi, pour une requête avec plusieurs colonnes, ce mode est inutile et présente les même iconvénients que FETCH_NUM (le numéro des colonnes changent si on change la requête, ce qui peut casser toute l’application). Autant modifier la requête pour ne récupérer qu’une seule colonne, en plus on économise sur le temps de transfert entre la base de données et l’application.

Et justement, ce mode devient réellement interressant lorsqu’il est utilisé pour une requête d’une seule colonne. En effet, avec FETCH_NUM on obtient un tableau de tableaux d’une seule case, par exemple :

Array
(
  [0] => Array
    (
      [0] => toto
    )
  [1] => Array
    (
      [0] => titi
    )
)

Avec FETCH_COLUMN, le resultat est donc nettement plus petit (et directement exploitable, parcequ’un tableau de tableaux c’est vraiment pas pratique), et le temps de récupération est légerement plus court :

• Temps de récupération : -9%
• Taille du résultat : -62% (!)

En résumé, pour récupérer une liste de valeurs, utilisez FETCH_COLUMN !

FETCH_KEY_PAIR

Nous venons de voir une méthode simple d’optimisation pour les requetes à une colonne. FETCH_KEY_PAIR est en quelque sorte l’équivalent pour les requêtes à 2 colonnes : il permet d’obtenir directement un tableau associatif avec la première colonne comme clef et la seconde comme valeur. J’adore !

Attention : ce mode ne fonctionne qu’avec fetchAll (lorsqu’on l’utilise avec setFetchMode ça provoque une erreur, voir bug #42917).

Exemple :

// SELECT id, login FROM user u';
$results->fetchAll(PDO::FETCH_KEY_PAIR);

// id => login
Array
(
  [1] => toto
  [2] => titi
)

Par rapport avec FETCH_BOTH :

• Temps de récupération : -14,8%
• Taille du résultat : -78% (!)

Ce mode est tout simplement génial dès qu’il s’agit de récupérer des couples de valeurs. Un exemple de cas très fréquent pour moi est de récupérer un id et un label dans une table de référence pour construire une liste déroulante dans un formulaire. Utiliser FETCH_KEY_PAIR au lieu de FETCH_NUM (ou FETCH_ASSOC) puis de construire le tableau associatif à la main permet d’économiser un peu de temps et beaucoup de mémoire. Bref, FETCH_KEY_PAIR c’est bon, mangez-en.

FETCH_BOUND

Ce mode permet d’extraire les valeurs directement dans des variables PHP, préalablement liées aux colonnes. Personnellement je ne comprends pas l’interet de ce mode et je ne l’ai jamais utilisé, mais si ça interresse quelqu’un, on peut trouver des exemples dans la doc de la fonction bindColumn.

FETCH_FUNC

Ce mode permet de définir une fonction callback pour récupérer les données. Ce mode ne fonctionne qu’avec fetchAll (si vous essayez de l’utiliser avec setFetchMode vous aurez droit à un joli message d’erreur du genre SQLSTATE[HY000]: General error: PDO::FETCH_FUNC is only allowed in PDOStatement::fetchAll()).

La fonction callback reçoit en paramètre toutes les colonnes (func_get_args peut être très utile) et doit retourner le résultat voulu.

Exemple pour émuler le comportement de FETCH_ASSOC :

function my_callback($id, $login)
{
	return array('id' => $id, 'login' => $login);
}
$results->fetchAll(PDO::FETCH_FUNC, 'my_callback');

Array
(
  [0] => Array
    (
      [id] => 1
      [login] => toto
    )

  [1] => Array
    (
      [id] => 2
      [login] => titi
    )
)

Le temps d’execution dépend évidemment du contenu de la fonction. A titre indicatif, avec le callback présenté en exemple, qui émule FETCH_ASSOC prend 70% plus de temps que la version native.

A suivre : les modes modificateurs.

FETCH_OBJ

Le tableau retourné contient les résultats sous forme d’instances de stdClass, contenant les valeurs des colonnes comme des variables publiques. Ce mode ne permet pas de récupérer plusieurs colonnes avec le même nom (voir FETCH_ASSOC).

Exemple :

Array
(
  [0] => stdClass Object
    (
      [id] => 1
      [login] => toto
    )

  [1] => stdClass Object
    (
      [id] => 2
      [login] => titi
    )

)

Par rapport à FETCH_BOTH :

• Temps de récupération : +7,6% (à noter qu’avec while + fetch, ça passe à +30%)
• Taille du résultat : -15%

Cette méthode est plus lente que la méthode par défaut (qui est déjà particulièrement lente), et honnetement, je ne vois pas l’avantage d’un objet par rapport à un tableau associatif renvoyé par FETCH_ASSOC…

FETCH_CLASS

Ce mode est équivalent à FETCH_OBJ sauf qu’il permet d’utiliser une classe personnalisée pour stocker les résultats. Ce mode ne permet pas de récupérer plusieurs colonnes avec le même nom (voir FETCH_ASSOC).

Ce mode nécessite de passer, en plus du mode, des paramètres supplémentaires. D’après la documentation, il faudrait utiliser la fonction setFetchMode pour passer ces paramètres (ou directement au moment de faire query), mais en pratique, fetchAll les accepte aussi (alors qu’ils ne sont censés exister)… Par contre, fetch ne les accepte pas.

Le deuxième paramètre est donc le nom d’une classe. Si la classe contient déjà des variables correspondantes aux colonnes, PDO les rempli et se fiche pas mal de leur visibilité. Sinon, PDO crée les variables avec une visibilité publique. Un troisième paramètre (optionnel) permet de passer des paramètres au constructeur de la classe. A noter que quand le constructeur est appellé, les variables internes ont déjà une valeur (voir FETCH_PROPS_LATE dans le dernier article de cette série si ce comportement pose un problème).

Si la classe n’existe pas, le résultat est un tableau identique à celui obtenu avec FETCH_BOTH (si un autre mode par défaut est défini, il n’est pas pris en compte).

Exemple :

class MyClass
{
  function __construct()
  {
    var_dump(func_get_args()); // affiche 'foo' et 'bar'
    var_dump($this->id, $this->login); // affiche l'id et le login
  }
}

$results = $dbh->query($sql);
$results->fetchAll(PDO::FETCH_CLASS, 'MyClass', array('foo', 'bar'));

Array
(
  [0] => MyClass Object
    (
      [id] => 1
      [login] => toto
    )

  [1] => MyClass Object
    (
      [id] => 2
      [login] => titi
    )

)

Les performances dépendent évidemment de la taille de la classe : plus il y a d’infos dedans, pire c’est. Avec une classe entièrement vide (c’est-à-dire avec meilleures performances possibles), on obtient, par rapport à FETCH_BOTH :

• Temps de récupération : +6% (à noter qu’avec while + fetch, ça passe à +32%)
• Taille du résultat : dépend de la taille de la classe

En déclarant un constructeur (même vide), les performances se dégradent énormement parceque le constructeur est appellé à chaque ligne de résultat :

• Temps de récupération : +55% (avec while + fetch, ça descend à +36%)
• Taille du résultat : dépend de la taille de la classe

Pour faire court : les performances sont catastrophiques par rapport aux modes classiques. Il est peut-être possible d’utiliser ce mode pour créer un petit ORM, mais pour l’instant je ne vois pas bien l’utilité.

FETCH_INTO

Ce mode permet de récupérer les données *dans* une instance de classe déjà existante…

Pour utiliser ce mode, il faut passer en paramètre la variable qui contient l’instance à modifier. Comme pour FETCH_CLASS, d’après la documentation il faut utiliser la fonction setFetchMode (ou directement query) pour passer ce paramètre. Et cette fois, curieusement, ni fetchAll ni fetch ne les accepte (avec fetchAll on obtient l’erreur plutôt originale SQLSTATE[HY000]: General error: Extraneous additional parameters).

La seule manière est donc d’utiliser :

class MyClass { }
$toto = new MyClass();
$results->setFechMode(PDO::FETCH_INTO, $toto);
// fetch

Attention, contrairement à FETCH_CLASS, si vous déclarez dans la classe les variables correspondant au nom des colonnes en protected ou private, PDO va retourner une erreur : Fatal error: Cannot access protected (ou private) property MyClass::$id.

Avec fetchAll, on obtient un tableau contenant exactement la même instance de classe autant de fois qu’il y a de lignes dans la réponse… L’instance contient uniquement les valeurs de la dernière ligne. C’est donc totalement inexploitable. Exemple :

Array
(
  [0] => MyClass Object
    (
      [id] => 2
      [login] => toto
    )

  [1] => MyClass Object
    (
      [id] => 2
      [login] => toto
    )

)

Si on utilise fetch dans une boucle while, fetch retourne à chaque étape une référence vers l’instance. Exemple :

while ( $r = $results->fetch() )
	var_dump($r == $toto); // affiche true

On peut donc utiliser :

while ( $results->fetch() )
	print_r($toto);

MyClass Object
(
  [id] => 1
  [login] => toto
)
MyClass Object
(
  [id] => 2
  [login] => titi
)

J’ai estimé les performances avec fetchAll afin de pouvoir comparer les résultats, mais il est important de noter qu’avec ce mode fetchAll ne sert à rien… Par rapport à FETCH_BOTH, on obtient :

• Temps de récupération : -3,5% (avec while + fetch ça descend à -9%)
• Taille du résultat : dépend de la taille de la classe

Le temps de récupération est plus court que FETCH_CLASS ou FETCH_OBJ car l’objet est déjà instancié. Mais, même si les performances sont correctes, pour l’instant je n’ai pas encore trouvé d’utilisation concrète pour ce mode.

A suivre : les modes spéciaux et les modes modificateurs.

Cette première partie est consacrée à la présentation des tests et aux modes “classiques”.

Présentation

Le mode de récupération peut être définis de plusieurs façons :

• directement en paramètre de la méthode query() ;
• avec la méthode setFetchMode() appliquée à l’objet de résultats ;
• en paramètre de la méthode fetchAll() ;
• en paramètre de la méthode fetch() ; dans ce cas le mode s’applique ligne par ligne, et il est ainsi possible de changer de mode pendant la récupération…

Attention, tous les modes ne peuvent pas s’utiliser avec toutes les méthodes (sinon ça serait trop simple) : certains fonctionnement seulement avec fetchAll, d’autres avec fetch, d’autres encore nécessitent obligatoirement un appel à setFetchMode pour passer des paramètres supplémentaires… C’est l’anarchie et ce n’est pas du tout documenté sur le site de PHP, alors si besoin est, je précise comment utiliser le mode.

Rappel à propros de fetchAll : il n’est pas recommandé de l’utiliser pour traiter de grosses requetes, car cela revient à mettre d’abord en mémoire la *totalité* des résultats pour les traiter ensuite. En utilisant fetch dans une boucle while, on met en mémoire une ligne et on la traite, puis la suivante réutilise la mémoire occupée, etc.

Les tests sont effectués avec PHP 5.2.4 (certains modes sont très récents). Le code utilisé pour afficher le résultat est le suivant (sauf mention contraire) :

$dbh = new PDO($dsn, $login, $password);
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$sql = 'SELECT id, login FROM user LIMIT 0,2';
$results = $dbh->query($sql);
print_r($results->fetchAll(PDO::FETCH_FOOBAR));

Enfin, je suppose que vous connaissez déjà PDO avant de lire cet article :-)

FETCH_BOTH

C’est le mode de récupération par défaut de PDO, et, selon moi, le moins utile et le moins efficace. Le tableau qui est retourné contient les résultats en double : une fois indexés par le nom des colonnes et une deuxième fois indexés par leur numéro. Personnellement, je n’utilise *jamais* les deux modes d’indexation en même temps ; c’est soit l’un, soit l’autre. Du coup, ce mode de récupération ne sert à rien. Pourquoi est-ce que c’est justement celui là le mode par défaut ? Mystère.

Exemple :

$results->fetchAll(PDO::FETCH_BOTH);

Array
(
  [0] => Array
    (
      [id] => 1
      [0] => 1
      [login] => toto
      [1] => toto
    )

  [1] => Array
    (
      [id] => 2
      [0] => 2
      [login] => titi
      [1] => titi
    )
)

J’ai mesuré le temps moyen mis à récupérer les résultats d’une requête de 100 lignes (sur 1000 executions), et la taille du tableau retourné, avec fetchAll, puis avec while ( $r = $results->fetch() ). Puisque c’est le mode par défaut, les résultats me servent de référence pour comparer avec les autres modes.

Note : depuis PHP 5.2.0 il est possible de modifier le mode de récupération par défaut avec :

$dbh->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_FOOBAR);

Ce mode sera utilisé lorsqu’aucun mode n’est précisé, mais parfois PDO revient malgré tout à FETCH_BOTH, alors on ne peut pas dire que ça soit très fiable.

FETCH_NUM

Le tableau retourné contient les résultats indexés par le numéro de la colonne.

Exemple :

$results->fetchAll(PDO::FETCH_NUM);

Array
(
  [0] => Array
    (
      [0] => 1
      [1] => toto
    )

  [1] => Array
    (
      [0] => 2
      [1] => titi
    )

)

Par rapport à FETCH_BOTH :

• Temps de récupération : -7,1%
• Taille du résultat : -23%

Ce mode est le plus rapide et retourne le tableau le plus petit. Mais il n’est pas toujours pratique de travailler avec le numéro des colonnes. D’autant plus que le moindre changement dans la requete SQL (suppression d’une colonne par exemple) risque de casser tout le reste du script ! En clair, à utiliser dans des cas très spécifiques et quand le nombre de colonnes est réduit pour ne pas risquer d’avoir une application impossible à maintenir.

FETCH_ASSOC

Le tableau retourné contient les résultats indexés par le nom de la colonne. Ce mode ne permet pas de récupérer plusieurs colonnes avec le même nom (une seule valeur est retournée, en général celle la plus à droite dans la requête, i.e. la dernière).

Exemple :

$results->fetchAll(PDO::FETCH_ASSOC);

Array
(
  [0] => Array
    (
      [id] => 1
      [login] => toto
    )

  [1] => Array
    (
      [id] => 2
      [login] => titi
    )

)

Par rapport à FETCH_BOTH :

• Temps de récupération : -4%
• Taille du résultat : -20%

Les performances sont legèrement moins bonnes que FETCH_NUM (mais toujours bien meilleures que le mode par défaut), mais un tableau associatif est *tellement* plus pratique à utiliser et plus facile à maintenir que ça n’a pas d’importance. C’est le mode que j’utilise par défaut.

FETCH_NAMED

Ce mode un peu particulier est identique à FETCH_ASSOC, sauf dans le cas où plusieurs colonnes portent le même nom dans la requete SQL : FETCH_ASSOC ne va retourner qu’une seule valeur tandis que FETCH_NAMED va retourner un tableau de valeurs.

Prenons par exemple la requete suivante (complètement inutile, juste pour l’exemple) :

SELECT email as id, id, login FROM user LIMIT 0,2;

Le résultat avec FETCH_ASSOC est identique à ci-dessus, et la première colonne n’est pas accessible. Avec FETCH_NAMED, on obtient :

$results->fetchAll(PDO::FETCH_NAMED);

Array
(
  [0] => Array
    (
      [id] => Array
        (
          [0] => 1
          [1] => toto@foo
        )

      [login] => toto
    )

  [1] => Array
    (
      [id] => Array
        (
          [0] => 2
          [1] => titi@foo
        )

      [login] => titi
    )

)

Bon, entre nous, si vous avez un jour besoin de ce mode, envisagez d’utiliser les alias de colonnes en SQL…

A suivre : les modes orientés objets, les modes spéciaux et les modes modificateurs.