There are basically three ways to store a tree in a relationnal databases : adjacency list, nested set and materialized path, plus a few more like nested intervals. Let’s put it clear : they all suck.

• Adjacency list model is the one I used the first time (with parent_id column). It’s easy to create but impossible to query deeply without recursivity.
• Nested set model is quite easy to query, but is indeed pretty fucked up (tree is limited in size, very hard to read without maths, almost all the lines of the table need to be updated each time a node is added, moved or deleted!). Nested intervals model tries to remove the size limitation of nested sets model, but involves way to much maths.
• Materialized path is great and easy to understand, but very slow because it involves heavy use of the “LIKE” operator.

More on that here, here and here.

Then I found two very interesting articles. One is a reply on MySQL Forums about materialized path performance problem, recommending an approach based on normalized schema to store paths. The other is an implementation using PostgreSQL by depesz that also use a normalized schema. The point is to create a table dedicated to store all the paths from every nodes to every nodes. This looks to me like a very good approach, as it’s easy to understand, easy to maintain, easy to query and performance-ok (with appropriate indexes). Unfortunalty, the implementation I found relies to much on PostgreSQL and doesn’t work out-of-the-box with MySQL (because of the use of triggers and of some queries that needs to be rewriten). So I reworked it to work with MySQL 5, and changed a few things. I strongly recommend that you read depesz’s post for a complete understanding of the approach before you continue.

Data Model

First, we create a table containing the data, let’s name it data. The parent_id column stores the parent’s ID, like in the traditionnal adjacency list approach, but we’re not going to use it for querying the tree. The value column is whatever you need to store as value for the node, and we’re going to use it for ordering. We use InnoDB as storage engine.

CREATE TABLE data (
	id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
	parent_id INTEGER UNSIGNED null,
	value VARCHAR(255) NOT NULL,

	PRIMARY KEY (id),

	INDEX data_data_fk (parent_id),
	FOREIGN KEY data_data_fk (parent_id) REFERENCES data (id) ON DELETE CASCADE
) ENGINE = InnoDB;

Then we create the table that will store every paths. A path contains a parent node, a child node, and the number of hops between the two nodes (depth). Each node has at least one entry on that table: the path to itself with a depth egal 0. The path column will hold the materialized path, that will be used for ordering. If you’re absolutely sure that you will never ever need to display your tree in alphabetical order, then you can safely remove this column and remove related queries from triggers.

CREATE TABLE data_tree (
	parent_id INTEGER UNSIGNED NOT NULL,
	child_id INTEGER UNSIGNED NOT NULL,
	depth INTEGER UNSIGNED NOT NULL default 0,
	path TEXT NOT NULL,

	PRIMARY KEY (parent_id, child_id),
	INDEX data_tree_child_depth_idx (child_id, depth),

	INDEX data_tree_parent_data_fk (parent_id),
	FOREIGN KEY data_tree_parent_data_fk (parent_id) REFERENCES data (id) ON DELETE CASCADE,
	INDEX data_tree_child_data_fk (child_id),
	FOREIGN KEY data_tree_child_data_fk (child_id) REFERENCES data (id) ON DELETE CASCADE,
);

Creating a new node

When a node is inserted in the table data, then every path leading to this node has to be inserted in the table data_tree. To achieve this, I use a trigger (MySQL 5 or higher) because it’s safer for the DB’s integrity, but a client side implementation (in PHP or any other langage) will do, as long as you use a transaction.

DELIMITER |
CREATE TRIGGER insert_data
AFTER INSERT ON data
FOR EACH ROW BEGIN
	INSERT INTO data_tree (parent_id, child_id, depth, path)
	VALUES (NEW.id, NEW.id, 0, CONCAT(NEW.value,"/"));

	INSERT INTO data_tree (parent_id, child_id, depth, path)
		SELECT parent_id, NEW.id, depth + 1, CONCAT(path, NEW.value, "/")
		FROM data_tree
		WHERE child_id = NEW.parent_id;
END; |
DELIMITER ;

Updating the tree

First possible update : moving a node. To move a node, we basically have to delete every path between the node’s ancestors (if any) to the node’s childs (if any), and then insert all the new paths. This can be done easily with two queries in a trigger, or again, if you prefer, client side. No big changes from depesz’s post, I only had to rewrite queries for MySQL.

Second possible update : changing a node’s value. This step is optionnal if you decided to drop the path column. When a node’s value is updated, for exemple from “Apinat” to “Banaanit”, then every path including that node value has to be updated as well, otherwise the tree won’t be correctly ordered. This step has to be completly rewriten for MySQL, has the original depesz’s implementation for PostgreSQL uses regexp replacements, which are not supported. Hence I came with a workaround, using only pure string functions to make the replacement.

DELIMITER |
CREATE TRIGGER update_data
AFTER UPDATE ON data
FOR EACH ROW BEGIN
	DECLARE old_path_len INT;
	IF NEW.parent_id != OLD.parent_id OR NEW.parent_id IS NULL OR OLD.parent_id IS NULL THEN
		if OLD.parent_id IS NOT NULL THEN
			DELETE t2
			FROM data_tree t1
			JOIN data_tree t2 ON t1.child_id = t2.child_id
			WHERE t1.parent_id = OLD.id
			AND t2.depth > t1.depth;
		END IF;

		IF NEW.parent_id IS NOT NULL THEN
			INSERT INTO data_tree (parent_id, child_id, depth, path)
				SELECT t1.parent_id, t2.child_id, t1.depth + t2.depth + 1, CONCAT(t1.path, t2.path)
				FROM data_tree t1, data_tree t2
				WHERE t1.child_id = NEW.parent_id
				AND t2.parent_id = OLD.id;
		END IF;
	END IF;

	IF NEW.value != OLD.value THEN
		SELECT CHAR_LENGTH(path) INTO old_path_len
		FROM data_tree
		WHERE child_id = OLD.id
		AND DEPTH = 0;

		IF old_path_len > 0 THEN
			UPDATE data_tree t1
			JOIN data_tree t2 ON t1.child_id = t2.child_id
			SET t2.path = CONCAT(
				SUBSTRING(t2.path, 1, CHAR_LENGTH(t2.path) - CHAR_LENGTH(t1.path)),
				CONCAT(NEW.value, SUBSTRING(t1.path, old_path_len))
			)
			WHERE t1.parent_id = OLD.id
			AND t2.depth >= t1.depth;
		END IF;
	END IF;
END; |
DELIMITER ;

Deleting a node

Thanks to the ON DELETE CASCADE clause, we don’t need to do anything when deleting a node. Beware that every childs will also be deleted from the tree and from the data table.

Examples

Let’s play a little with this implementation.

Populating the tree

mysql> INSERT INTO data (parent_id, value) VALUES (null, 'Heavy metal');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM data;
+----+-----------+-------------+
| id | parent_id | value       |
+----+-----------+-------------+
|  1 |      NULL | Heavy metal |
+----+-----------+-------------+
1 row in set (0.00 sec)

mysql> SELECT * FROM data_tree;
+-----------+----------+-------+--------------+
| parent_id | child_id | depth | path         |
+-----------+----------+-------+--------------+
|         1 |        1 |     0 | Heavy metal/ |
+-----------+----------+-------+--------------+
1 row in set (0.00 sec)

mysql> INSERT INTO data (parent_id, value) VALUES (1, 'Power metal'), (1, 'Trash metal'), (1, 'Death metal');
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM data;
+----+-----------+-------------+
| id | parent_id | value       |
+----+-----------+-------------+
|  1 |      NULL | Heavy metal |
|  2 |         1 | Power metal |
|  3 |         1 | Trash metal |
|  4 |         1 | Death metal |
+----+-----------+-------------+
4 rows in set (0.00 sec)

mysql> SELECT * FROM data_tree;
+-----------+----------+-------+--------------------------+
| parent_id | child_id | depth | path                     |
+-----------+----------+-------+--------------------------+
|         1 |        1 |     0 | Heavy metal/             |
|         1 |        2 |     1 | Heavy metal/Power metal/ |
|         1 |        3 |     1 | Heavy metal/Trash metal/ |
|         1 |        4 |     1 | Heavy metal/Death metal/ |
|         2 |        2 |     0 | Power metal/             |
|         3 |        3 |     0 | Trash metal/             |
|         4 |        4 |     0 | Death metal/             |
+-----------+----------+-------+--------------------------+
7 rows in set (0.00 sec)

mysql> INSERT INTO data (parent_id, value) VALUES (2, 'Symphonic power metal'), (2, 'Extreme power metal'), (4, 'Brutal death metal');
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM data_tree;
+-----------+----------+-------+------------------------------------------------+
| parent_id | child_id | depth | path                                           |
+-----------+----------+-------+------------------------------------------------+
|         1 |        1 |     0 | Heavy metal/                                   |
|         1 |        2 |     1 | Heavy metal/Power metal/                       |
|         1 |        3 |     1 | Heavy metal/Trash metal/                       |
|         1 |        4 |     1 | Heavy metal/Death metal/                       |
|         1 |        5 |     2 | Heavy metal/Power metal/Symphonic power metal/ |
|         1 |        6 |     2 | Heavy metal/Power metal/Extreme power metal/   |
|         1 |        7 |     2 | Heavy metal/Death metal/Brutal death metal/    |
|         2 |        2 |     0 | Power metal/                                   |
|         2 |        5 |     1 | Power metal/Symphonic power metal/             |
|         2 |        6 |     1 | Power metal/Extreme power metal/               |
|         3 |        3 |     0 | Trash metal/                                   |
|         4 |        4 |     0 | Death metal/                                   |
|         4 |        7 |     1 | Death metal/Brutal death metal/                |
|         5 |        5 |     0 | Symphonic power metal/                         |
|         6 |        6 |     0 | Extreme power metal/                           |
|         7 |        7 |     0 | Brutal death metal/                            |
+-----------+----------+-------+------------------------------------------------+
16 rows in set (0.00 sec)

mysql> SELECT * FROM data;
+----+-----------+-----------------------+
| id | parent_id | value                 |
+----+-----------+-----------------------+
|  1 |      NULL | Heavy metal           |
|  2 |         1 | Power metal           |
|  3 |         1 | Trash metal           |
|  4 |         1 | Death metal           |
|  5 |         2 | Symphonic power metal |
|  6 |         2 | Extreme power metal   |
|  7 |         4 | Brutal death metal    |
+----+-----------+-----------------------+
7 rows in set (0.00 sec)

Requesting the tree

First generation of childs FROM “Heavy metal”

mysql> SELECT d.id, d.value
       FROM data_tree t
       JOIN data d ON d.id = t.child_id
       WHERE t.parent_id = 1
       AND depth = 1;
+----+-------------+
| id | value       |
+----+-------------+
|  2 | Power metal |
|  3 | Trash metal |
|  4 | Death metal |
+----+-------------+
3 rows in set (0.00 sec)

Printing the whole tree, ordered

mysql> SELECT CONCAT(REPEAT('-',t.depth), d.value) AS value
       FROM data_tree t
       JOIN data d ON d.id = t.child_id
       WHERE t.parent_id = 1
       ORDER by t.path;
+-------------------------+
| value                   |
+-------------------------+
| Heavy metal             |
| -Death metal            |
| --Brutal death metal    |
| -Power metal            |
| --Extreme power metal   |
| --Symphonic power metal |
| -Trash metal            |
+-------------------------+
7 rows in set (0.00 sec)

Ancestors of “Symphonic power metal”, starting from the root

mysql> SELECT d.id, d.value
       FROM data_tree t
       JOIN data d ON d.id = t.parent_id
       WHERE t.child_id = 5
       ORDER BY depth DESC;
+----+-----------------------+
| id | value                 |
+----+-----------------------+
|  1 | Heavy metal           |
|  2 | Power metal           |
|  5 | Symphonic power metal |
+----+-----------------------+
3 rows in set (0.00 sec)

Updating the tree

Moving a node to another place

Let’s add a Hard rock in our tree, and move Heavy metal as a child of Hard rock.

mysql> INSERT INTO data (parent_id, value) VALUES (null, 'Hard rock');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM data;
+----+-----------+-----------------------+
| id | parent_id | value                 |
+----+-----------+-----------------------+
|  1 |      NULL | Heavy metal           |
|  2 |         1 | Power metal           |
|  3 |         1 | Trash metal           |
|  4 |         1 | Death metal           |
|  5 |         2 | Symphonic power metal |
|  6 |         2 | Extreme power metal   |
|  7 |         4 | Brutal death metal    |
|  8 |      NULL | Hard rock             |
+----+-----------+-----------------------+
8 rows in set (0.00 sec)

mysql> UPDATE data SET parent_id = 8 WHERE id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> SELECT * FROM data;
+----+-----------+-----------------------+
| id | parent_id | value                 |
+----+-----------+-----------------------+
|  1 |         8 | Heavy metal           |
|  2 |         1 | Power metal           |
|  3 |         1 | Trash metal           |
|  4 |         1 | Death metal           |
|  5 |         2 | Symphonic power metal |
|  6 |         2 | Extreme power metal   |
|  7 |         4 | Brutal death metal    |
|  8 |      NULL | Hard rock             |
+----+-----------+-----------------------+
8 rows in set (0.00 sec)

mysql> SELECT * FROM data_tree;
+-----------+----------+-------+----------------------------------------------------------+
| parent_id | child_id | depth | path                                                     |
+-----------+----------+-------+----------------------------------------------------------+
|         1 |        1 |     0 | Heavy metal/                                             |
|         1 |        2 |     1 | Heavy metal/Power metal/                                 |
|         1 |        3 |     1 | Heavy metal/Trash metal/                                 |
|         1 |        4 |     1 | Heavy metal/Death metal/                                 |
|         1 |        5 |     2 | Heavy metal/Power metal/Symphonic power metal/           |
|         1 |        6 |     2 | Heavy metal/Power metal/Extreme power metal/             |
|         1 |        7 |     2 | Heavy metal/Death metal/Brutal death metal/              |
|         2 |        2 |     0 | Power metal/                                             |
|         2 |        5 |     1 | Power metal/Symphonic power metal/                       |
|         2 |        6 |     1 | Power metal/Extreme power metal/                         |
|         3 |        3 |     0 | Trash metal/                                             |
|         4 |        4 |     0 | Death metal/                                             |
|         4 |        7 |     1 | Death metal/Brutal death metal/                          |
|         5 |        5 |     0 | Symphonic power metal/                                   |
|         6 |        6 |     0 | Extreme power metal/                                     |
|         7 |        7 |     0 | Brutal death metal/                                      |
|         8 |        1 |     1 | Hard rock/Heavy metal/                                   |
|         8 |        2 |     2 | Hard rock/Heavy metal/Power metal/                       |
|         8 |        3 |     2 | Hard rock/Heavy metal/Trash metal/                       |
|         8 |        4 |     2 | Hard rock/Heavy metal/Death metal/                       |
|         8 |        5 |     3 | Hard rock/Heavy metal/Power metal/Symphonic power metal/ |
|         8 |        6 |     3 | Hard rock/Heavy metal/Power metal/Extreme power metal/   |
|         8 |        7 |     3 | Hard rock/Heavy metal/Death metal/Brutal death metal/    |
|         8 |        8 |     0 | Hard rock/                                               |
+-----------+----------+-------+----------------------------------------------------------+
24 rows in set (0.00 sec)

mysql> SELECT CONCAT(REPEAT('-',t.depth), d.value) AS value
       FROM data_tree t
       JOIN data d ON d.id = t.child_id
       WHERE t.parent_id = 8
       ORDER BY t.path;
+--------------------------+
| value                    |
+--------------------------+
| Hard rock                |
| -Heavy metal             |
| --Death metal            |
| ---Brutal death metal    |
| --Power metal            |
| ---Extreme power metal   |
| ---Symphonic power metal |
| --Trash metal            |
+--------------------------+
8 rows in set (0.00 sec)

Changing a node’s value

Ok, I don’t know why we would do that, but let’s just rename Death metal to ZDeath metal and see what happens.

mysql> UPDATE data SET value = 'ZDeath metal' WHERE id = 4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> SELECT * FROM data_tree;
+-----------+----------+-------+----------------------------------------------------------+
| parent_id | child_id | depth | path                                                     |
+-----------+----------+-------+----------------------------------------------------------+
|         1 |        1 |     0 | Heavy metal/                                             |
|         1 |        2 |     1 | Heavy metal/Power metal/                                 |
|         1 |        3 |     1 | Heavy metal/Trash metal/                                 |
|         1 |        4 |     1 | Heavy metal/ZDeath metal/                                |
|         1 |        5 |     2 | Heavy metal/Power metal/Symphonic power metal/           |
|         1 |        6 |     2 | Heavy metal/Power metal/Extreme power metal/             |
|         1 |        7 |     2 | Heavy metal/ZDeath metal/Brutal death metal/             |
|         2 |        2 |     0 | Power metal/                                             |
|         2 |        5 |     1 | Power metal/Symphonic power metal/                       |
|         2 |        6 |     1 | Power metal/Extreme power metal/                         |
|         3 |        3 |     0 | Trash metal/                                             |
|         4 |        4 |     0 | ZDeath metal/                                            |
|         4 |        7 |     1 | ZDeath metal/Brutal death metal/                         |
|         5 |        5 |     0 | Symphonic power metal/                                   |
|         6 |        6 |     0 | Extreme power metal/                                     |
|         7 |        7 |     0 | Brutal death metal/                                      |
|         8 |        1 |     1 | Hard rock/Heavy metal/                                   |
|         8 |        2 |     2 | Hard rock/Heavy metal/Power metal/                       |
|         8 |        3 |     2 | Hard rock/Heavy metal/Trash metal/                       |
|         8 |        4 |     2 | Hard rock/Heavy metal/ZDeath metal/                      |
|         8 |        5 |     3 | Hard rock/Heavy metal/Power metal/Symphonic power metal/ |
|         8 |        6 |     3 | Hard rock/Heavy metal/Power metal/Extreme power metal/   |
|         8 |        7 |     3 | Hard rock/Heavy metal/ZDeath metal/Brutal death metal/   |
|         8 |        8 |     0 | Hard rock/                                               |
+-----------+----------+-------+----------------------------------------------------------+
24 rows in set (0.00 sec)

mysql> SELECT CONCAT(REPEAT('-',t.depth), d.value) AS value
       FROM data_tree t
       JOIN data d ON d.id = t.child_id
       WHERE t.parent_id = 8
       ORDER by t.path;
+--------------------------+
| value                    |
+--------------------------+
| Hard rock                |
| -Heavy metal             |
| --Power metal            |
| ---Extreme power metal   |
| ---Symphonic power metal |
| --Trash metal            |
| --ZDeath metal           |
| ---Brutal death metal    |
+--------------------------+
8 rows in set (0.00 sec)

L’algorithme le plus répandu pour calculer un hash est MD5. Néanmoins, depuis 2004 plusieurs vulnérabilités ont été découvertes, aussi il est préférable d’utiliser SHA1. Quel est meilleur type pour stocker ces hashs dans une table MySQL ?

Un hash SHA1 mesure 160 bits ou 40 caractères hexadécimaux. Un hash MD5 mesure 128 bits soit 32 caractères hexadécimaux.

Stocker sous forme de chaine

La longueur du hash est fixe : il est donc préférable d’utiliser le type CHAR (CHAR(40) pour du SHA1, CHAR(32) pour du MD5). En effet, le type VARCHAR prendrait plus d’espace car il utilise un octet supplémentaire pour stocker la longueur de la chaine.

Ensuite, il faut faire attention à l’encodage. En effet, si la table est en UTF-8, les caractères seront probablement stockés sur 3 octets (ça peut varier selon le moteur de stockage). Il vaut mieux spécifier l’encodage de cette colonne à ASCII, grâce à CHARACTER SET ascii.

Enfin, la colonne est évidemment NOT NULL, pour économiser un bit (la valeur NULL est stockée dans un bit supplémentaire), à moins que l’application en ait besoin (ça existe des utilisateurs sans mot de passe ?).

Exemple :

mysql> create table t (
    -> password char(40) character set ascii not null
    -> ) engine=MyISAM character set utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into t values(SHA1('monSuperMotDePasse'));
Query OK, 1 row affected (0.00 sec)

mysql> select * from t;
+------------------------------------------+
| password                                 |
+------------------------------------------+
| 35ea5a462298bd78c1648fbea2195988c46d103f |
+------------------------------------------+
1 row in set (0.00 sec)

L’espace utilisé est donc 40 octets pour un hash SHA1, car le type CHAR avec le jeu de caractère ASCII stocke chaque caractère sur un octet (8 bits).

Stocker sous forme binaire

Vous l’aurez surement remarqué, 40 octets ça fait 320 bits, c’est à dire le double de la taille du hash SHA1 brut (idem pour MD5 : 32×8 = 256). Pour faire simple, c’est le prix à payer pour avoir un mot de passe lisible et “imprimable” (c’est à dire que vous pouvez copier/coller sans problème) en base. L’autre solution consiste à stocker le hash brut directement sous forme binaire.

Le type a utilisé n’est donc plus CHAR, mais BINARY qui stocke des chaines binaires. Il faut lui préciser la longueur en octets, donc BINARY(20) pour du SHA1 (160/8 = 20), et BINARY(16) pour du MD5 (128/8 = 16). Il n’y a plus à se soucier du jeu de caractères.

Pour convertir une chaine de caractère en chaine binaire, il faut utiliser UNHEX. Pour l’opération inverse, il faut utiliser HEX. Note pour les utilisateurs de PHP : la fonction hash accepte un troisième paramètre optionnel $raw_output qui, s’il vaut true, permet de récupérer le résultat binaire directement (voir http://fr.php.net/manual/fr/function.hash.php).

Exemple :

mysql> create table t2 (
    -> password binary(20) not null
    -> ) engine=MyIsam character set utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into t2 values(UNHEX(SHA1('monSuperMotDePasse')));
Query OK, 1 row affected (0.00 sec)

mysql> select HEX(password) from t2;
+------------------------------------------+
| HEX(password)                            |
+------------------------------------------+
| 35EA5A462298BD78C1648FBEA2195988C46D103F |
+------------------------------------------+
1 row in set (0.00 sec)

L’espace utilisé est donc 20 octets pour hash SHA1, soit 2 fois moins que la version en chaine de caractères. L’inconvénient est qu’il faut penser à utiliser UNHEX ou HEX dès qu’on veut le hash sous une forme imprimable. C’est rarement le cas, et comme les opérations de comparaisons (utilisées pour l’authentification de l’utilisateur) peuvent s’effectuer avec les version binaires, ça ne me dérange pas.

En savoir plus

• The CHAR and VARCHAR Types
• Column Character Set and Collation
• The BINARY and VARBINARY Types
• Make Your Data as Small as Possible

Tableau de correspondance des tailles (source : http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html)

Alors quel est l’intérêt de la préciser une taille ? Il n’y en a qu’un seul, c’est lorsque le type est utilisé avec l’option zerofill, option assez peu connue qui permet de compléter avec le champ avec des zéros pour atteindre la taille spécifiée.

Exemple :

mysql> create table test_int (
    -> normal_int int unsigned not null,
    -> zerofilled_int int(6) unsigned zerofill not null
    -> );
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test_int values (123456789, 123456789), (42,42);
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> select * from test_int;
+------------+----------------+
| normal_int | zerofilled_int |
+------------+----------------+
|  123456789 |      123456789 |
|         42 |         000042 |
+------------+----------------+
2 rows in set (0.00 sec)

Comme vous pouvez le constater dans l’exemple précédent, il n’y aucune différence sur la première ligne (un nombre composé de 9 chiffres tient sans problème dans un int(6)), par contre dans la seconde, le champ avec l’option zerofill est complété par des zéros pour atteindre 6 chiffres. Un exemple concret d’utilisation : stocker des numéros de série normalisé (genre des numéros de bon de commande du type “BDC-000042″), car ça évite de faire un padding.

Bref, tout ça pour dire : ça ne sert à rien d’essayer d’optimiser ses tables MySQL avec ça, ce n’est pas en mettant int(4) qu’on va gagner de la place, mais plutôt en utilisant le type adapté (en l’occurence smallint).

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.

Contraintes liées au développement web collaboratif

Contrairement à un projet classique qui ne nécessite “que” un compilateur et des bibliothèques, une application web est une association complexe de plusieurs composants logiciels dont les versions et les configurations très variables peuvent influer sur le bon fonctionnement de l’application :

• un serveur web (vhost, htaccess, mod_rewrite, etc.),
• l’interpréteur php (options de php.ini, modules supplémentaires comme pdo, gettext, etc.),
• le sgbd (configuration des users, etc.).

Donc la solution “classique” d’avoir un poste de développement par développeur est ici difficile à maintenir : il faudrait installer tous ces logiciels sur chaque poste et surtout veiller à avoir une configuration identique partout. Et ça se complique dès qu’il faut faire une mise à jour de la config…

Une autre solution serait d’avoir un serveur de dev unique (pour éviter les problèmes de maintenance évoqués ci-avant), et de travailler directement dessus via des partages de fichiers (Samba, NFS, etc.). Or cette solution pose plusieurs problèmes :

• en cas d’accès concurrents à un fichier : le risque est grand de voir ses modifications écrasées par un autre développeur ;
• en cas de modifications lourdes (exemple : un refactoring de la base) : les autres développeurs sont bloqués ;
• impossible d’utiliser correctement le svn : il n’y a qu’une seule version des fichiers et on ne sait pas qui l’a modifiée.

Nous avons donc créée une solution intermédiaire : un serveur de dev unique (pour une maintenance facile), qui fournit des serveurs virtuels pour chaque développeur (pour une bonne séparation des données et une utilisation optimale de svn).

Le serveur de dev fonctionne avec Debian GNU/Linux, les postes clients avec Windows XP.

Plateforme technique

Compte sur le serveur

Chaque développeur dispose d’un compte uniquement sur le serveur de dev, qui lui permet de se connecter dessus en SSH (bien utile pour tester des tâches en ligne de commande tel que des scripts de maintenance). De plus, tous les développeurs appartiennent au même groupe (www) et les permissions sont par défaut en rw pour le groupe.

Partage Windows : Samba

Grace à Samba, chaque développeur dispose d’un partage windows identifié par son login. Le partage est également accessible en local sur la machine, dans son home.

Vhost Apache

Pour chaque dossier créé dans le partage, il existe un vhost permettant d’y accéder, sous la forme http://login.dossier.dev.bso.

Exemple, je crée le dossier monboprojet dans mon partage monbologin. L’URL est : http://monbologin.monboprojet.dev.bso

Pour les projets dont le documentRoot n’est pas à la racine (c’est à dire à peut près tous les projets sur svn, puisque la racine contient seulement trunk/, branches/ et tags/), il vaut mieux les mettre dans un répertoire suffixé par “-src” et faire un lien symbolique. Par exemple :

$ svn checkout http://mon.beau.svn/monboprojet monboprojet-src
$ ln -s monboprojet-src/trunk/htdocs monboprojet

BDD Mysql

Il n’y a qu’un seul serveur MySQL. Chaque développeur peut disposer de son propre compte et de ses propres bases. Cependant, pour des raisons pratiques, on utilise la plupart du temps les mêmes bases. Un développeur ne va utiliser des bases à part que s’il a besoin de faire des opérations lourdes (genre modifier la structure d’un ensemble de tables) qui bloqueraient tout le monde le temps que le code mis à jour soit commit.

Coordination du développement

SVN

Un serveur Subversion (SVN) est utilisé pour gérer les sources. Le serveur svn est sur une machine différente du serveur de dev ce qui permet de sécuriser les données (en cas de crash de la machine de dev, on peut récupérer les dépots ; en cas de crash de la machine svn, on a toujours les versions locales).

Les dépots sont organisés de la manière classique avec 3 repertoires :

• branches/
• trunk/
• tags/

Un commit ne doit pas casser le dépôt. C’est à dire qu’un développeur qui ferait un update doit pouvoir continuer à utiliser l’application sans être bloqué par un bug, une fonctionnalité manquante, ou autre. Il est tout à fait possible de faire un commit d’une feature non terminée, à partir du moment où le reste de l’application n’est pas impacté.

Fichiers de config

On ne commit jamais un fichier de config. En effet, d’une part un fichier de configuration est spécifique à un environnement (options de mise en cache, url, etc.) et d’autre part un fichier de configuration contient des logins et des mots de passes spécifiques.

On commit donc des modèles de fichiers de configuration, dont le nom se termine par .orig. Chaque développeur doit créer ses propres fichiers à partir des modèles. Quand on voit passer un “.orig” dans les logs d’update, on sait qu’il faut mettre à jour ce fichier. Cela est valable également pour les livraisons.

SQL

Pour permettre les livraisons (en préprod et en prod), à chaque modification de la base un fichier sql contenant les requêtes de mise à jour (alter, etc.) doit être écrit par le développeur. Pour éviter d’en avoir trop à gérer, il est intéressant de créer un fichier de mise à jour sql par version que l’on a prévu de livrer (upgrade_1.0.sql, upgrade_1.1.sql, etc.)

Livraison

Pour livrer, un développeur (en général le responsable du projet) utilise rsync depuis sa copie locale sur la machine de dev pour synchroniser les sources avec la préprod ou la prod. Puis il se connecte en SSH pour executer les scripts d’upgrade sql (d’où l’interet de les avoir écrit au fur et à mesure) et mettre à jour les fichiers de config.

Une option interessante de rsync est --exclude-from=nom_de_fichier, qui permet d’exclure du rsync tous les fichiers ou les répertoires qui matchent les noms présents dans nom_de_fichier. Très pratique pour éviter de livrer les fichiers inutiles (.svn, .mo, …) et éviter d’écraser les fichiers de config… Exemple de fichier d’exclusion :

.svn
rsync*
doc*
config/*
Thumbs.db
*.mo

select * from ma_table where id = 42 = 0;

La réponse est : toute la table sauf la ligne dont l’id vaut 42 ! En fait, en raison de la précédence des opérateurs, cette requête est équivalente à :

select * from ma_table where (id = 42) = 0

Comme l’opérateur de comparaison = retourne 0 (FALSE) ou 1 (TRUE) (ou NULL si un des 2 arguments vaut NULL), l’expression id = 42 = 0 est parfaitement valide et est équivalente à id != 42.

Mais à quoi ça sert me direz-vous ? A faire des injections SQL dans un site PHP qui ne filtre pas correctement ses variables… A bon entendeur !

Disons que la table qui a été créée ressemble à ça :

create table enum_is_evil (
  id integer not null auto_increment,
  value enum('0','1') not null default '0',
  primary key (id)
);

insert into enum_is_evil (value) values ('0'), ('0'), ('1');

Si on ne fait pas gaffe qu’il s’agit d’un enum et pas d’un type numérique (comme on pourrait logiquement le supposer), voila ce que ça donne…

mysql> select * from enum_is_evil where value = 0;
Empty set (0.00 sec)

Bon, aucun résultat alors qu’on devrait en avoir 2… Essayons autre chose.

mysql> select * from enum_is_evil where value = 1;
+----+-------+
| id | value |
+----+-------+
|  1 | 0     |
|  2 | 0     |
+----+-------+
2 rows in set (0.00 sec)

Youpi ! C’est n’importe quoi !

Et voyons ce qui se passe quand on ne fait pas attention à l’insertion, c’est encore plus drole.

insert into enum_is_evil (value) values (0), (0), (1);

Note : cette requête produit des warnings (logique), mais lorsqu’elle est executée dans un script, il n’y aucune chance de s’en apercevoir.

mysql> select * from enum_is_evil where value = 0;
+----+-------+
| id | value |
+----+-------+
|  4 |       |
|  5 |       |
+----+-------+
2 rows in set (0.00 sec)

Yeah, des valeurs vides dans la table alors qu’on devrait avoir uniquement des 0 ou des 1 !

mysql> select * from enum_is_evil where value = 1;
+----+-------+
| id | value |
+----+-------+
|  1 | 0     |
|  2 | 0     |
|  6 | 0     |
+----+-------+
3 rows in set (0.00 sec)

Encore mieux, la valeur “1″ qu’on a ajoutée est devenue un “0″ !

Conclusion : bien que tout ça soit logique quand on lit la doc du type ENUM (il suffit d’ajouter des quotes autour des valeurs pour obtenir les bons résultats), c’est une source d’erreur potentielle assez vicieuse quand on s’attend à travailler avec un type numérique. Utilisez plutôt un TINYINT !

select group_concat(column_name SEPARATOR ";")
from information_schema.columns
where table_schema = 'DB_NAME' and table_name = 'TABLE_NAME'
group by table_name;

La requête suivant permet d’exporter une table complète en CSV, sans passer par un langage de script (à condition d’avoir la permission FILE).

select *
into outfile '/tmp/foo.csv'
fields terminated by ';' optionally enclosed by '"'
lines terminated by '\n'
from DB_NAME.TABLE_NAME;

Plus d’infos dans la doc de MySQL.