Lors de la création d'une base de données (ou d'une table, plus simplement), on peut être amené à devoir stocker des informations qui se caractériseraient par un booléen. Cependant, certains SGBD ne disposent pas d'un type natif pour les prendre en charge.

Que faire ? Quel type utiliser ?

Si l'on navigue sur le web, on peut lire différentes suggestions quant au type à adopter, pourtant, les avis divergent, et il est difficile de trancher.

Dans le cas de MySQL, les propositions les plus communes sont d'utiliser un type ENUM, un type CHAR, ou un type TINYINT; mais l'un vaut-il mieux qu'un autre ?

Afin de trancher sur cette question j'ai réalisé quelques benchmarks. Si l'on se limite à la notion de poids, tous on le même impact sur le SGDB; il tient donc de s'intéresser aux performances.

Les tests réalisés ici sont des insertions (10M par jeu de test), on en mesure le temps, la base (100%) correspond au temps le plus fort constaté.


On remarque que les performances varient de près de 14% sur l'ensemble des tests. Par ailleurs, une différence est notable entre les 2 types ENUM, l'un employant le nom complet du booléen, tandis que le second sa première lettre. Si la représentation en base de données est la même, alors on peut interpréter cette différence de performance par le temps plus important de transfert et de traitement d'une requête plus longue.
Si un type ENUM court, ou un CHAR ont des performances proches, le type TINYINT sort du lot avec une performance en temps 7 à 8% meilleure.


La sélection se fait sur des jeux de tests de 100k SELECT.


Le constat pour les types ENUM se confirme ici encore.
Le type CHAR est le type qui semble le plus efficace, cependant, si l'on s'intéresse à l'échelle, on remarque que la performance n'est guère améliorée de plus de 0,5%, si on le compare à un TINYINT.

Conclusion :
* le type ENUM s'avère être le moins efficace des types ci-dessus cités
* le type CHAR semble plus performant sur les SELECT que le TINYINT mais
pas de manière notable.
* le type TINYINT sort grand vainqueur pour implémenter un booléen sous MySQL

Cependant, CHAR et TINYINT sont peu explicites dans le code, à moins de faire appel à une constante; qui en plus de favoriser la lisibilité, faciliterait le passage vers un type booléen, s'il venait à être proposé par le SGBD.