Blog Emmanuel Orchanian

astuce bdd bureautique codage culture débat design énigme français hacking html mathématiques méthodologie santé typographie 

 

 [669 vues] 2021-12-07 Emmanuel Orchanian

NOTE : cet article a été affiché dans sa langue originale.

Programmer multi-support avant tout !

MySQL, Oracle, Postgre et tout autre SGBD (Système de gestion de base de données) sont concurrents entres eux et jouent souvent à qui est le meilleur.

En général, il faut programmer de telle sorte à avoir le code qui fonctionne sur le plus de supports possibles. Ainsi, s'il faut un jour changer de SGBD, on ne s'arrache pas les cheveux, en d'autres termes, le patron n'aura pas à payer son équipe de plusieurs développeurs pendant plusieurs jours (voir semaines) pour changer de SGBD et par la suite réparer des bugs...
À noter également que souvent, si on change de SGBD, c'est qu'on a de plus en plus de quantité de données, en d'autres termes qu'une erreur vaut des erreurs à la chaîne.

Tout ça pour dire que tous les SGBD ne savent par lire les booléens...

Que faire alors ? la bonne solution serait d'utiliser les entiers : 0 pour faux, et 1 pour vrai, en préférant les TINYINT.

Pour les personnes utilisant phpMyAdmin

Vous n'avez rien à faire !

En effet, si vous sélectionnez le type BOOLEAN, vous vous rendrez compte après avoir validé, si vous revenez dans l'onglet Structure, que phpMyAdmin a automatiquement transformé votre BOOLEAN en TINYINT, gentil garçon !

TINYINT au lieu de INT

Vous pouvez vous permettre d'utiliser les TINYINT au lieu des INT.

Je pourrai image en disant que si un objet rentre dans un petit carton, alors il peux aussi rentrer dans un plus gros carton. Par contre l'inverse n'est pas toujours vrai !

Ca ne posera pas problème si vous allez sur un SGBD qui ne gère pas les INT, parce ce que tous les SGBD gèrent les INT, et votre TINYINT se transformera en INT, puisque qui peux le plus peut le moins, un TINYINT étant plus petit qu'un INT, ça ne posera aucun souci.

Ce qui est gênant c'est quand on passe de quelque chose de grand à quelque chose de plus petit.

Définitions selon phpMyAdmin :

  • INT : Un nombre entier de 4 octets. La fourchette des entiers relatifs est de -2 147 483 648 à 2 147 483 647. Pour les entiers positifs, c'est de 0 à 4 294 967 295
  • Les TINYINT : Un nombre entier de 1 octet. La fourchette des nombres avec signe est de -128 à 127. Pour les nombres sans signe, c'est de 0 à 255

Que penser du gaspillage ?

Calcul du gaspillage

Un booléen, c'est true ou false, un seul bit suffirait (0 ou 1)

Or le TINYINT utilise 8 bits (00000000 ou 00000001), 7 bits sont gaspillés, donc 27 = 128 possibilités gaspillées.

Avec un INT, on a 4 octets, donc 8*4 = 32, donc 31 bits gaspillés. 231 = 2 147 483 648 (2 milliards) possibilités gaspillées, pour un seul enregistrement.

Quelle décision prendre par rapport au gaspillage ?

Premièrement, il faut savoir que 2 milliards, c'est impressionnant, mais pour un ordinateur c'est rien.

Ce n'est pas du gaspillage par rapport à la responsabilité que c'est de changer de SGBD, et puis ne pensez pas que c'est seulement parce ce que vous aurez mis les BOOLEAN en nombre que vous n'aurez pas de problèmes, malheureusement...

Changer de SGBD est quelque chose de lourd, il vaut mieux avoir les bases les plus souples possibles, et cela prévôt sur le gaspillage.

Faut il autoriser les NULL ?

Précisions : en informatique souvent la valeur NULL signifie "rien du tout", "non rensigné", ou "néant". Ce n'est pas une valeur mais une absence de valeur, c'est plus un marqueur disons.

Prenez le soin de désactiver les NULL sinon au lieu de deux valeurs possibles, ce qui est la définition d'un booléen, on en aurait trois...

  1. TRUE
  2. FALSE
  3. NULL

Or il ne faut que :

  1. TRUE
  2. FALSE

Je nuancerai car parfois, on a besoin de savoir si la personne a renseigné un champs, par exemple à la question "avez-vous des enfants ?", on peux avoir trois solutions :

  1. Oui
  2. Non
  3. La personne n'a pas répondu à la question

Mais dans ce cas, on sort par définition du cas où on aurait un booléen... Je dirai presque que c'est un autre débat, et que si on parle de booléen, il faut bel et bien interdire les NULL.

Mon expérience personnelle

Ce fait de ne jamais mettre de BOOLEAN et lui préférer un TINYINT dans les bases de données, je l'avais appris à l'école puis j'avais aussi expérimenté les graves conséquences en entreprise, j'ai de l'expérience dans les bases de données, mais je vous conseillerai toujours de d'abord demander aux vrais experts, c'est-à-dire ceux qui ont minimum 10 ans d'expérience, et dans ce domaine précis !

Merci d'avoir lu !
Si en général vous avez une question, une curiosité, n'hésitez pas me contacter.