Quel type de données MySQL utiliser pour stocker des valeurs booléennes

Pour MySQL 5.0.3 et versions ultérieures, vous pouvez utiliser BIT . Le manuel dit:

A partir de MySQL 5.0.3, le type de données BIT est utilisé pour stocker les valeurs de champs de bits. Un type de BIT (M) permet de stocker des valeurs de M bits. M peut aller de 1 à 64.

Sinon, selon le manuel de MySQL, vous pouvez utiliser bool et boolean qui sont actuellement des alias de tinyint (1):

Bool, Boolean: Ces types sont des synonymes pour TINYINT (1). Une valeur de zéro est considérée comme fausse. Les valeurs non nulles sont considérées comme vraies.

MySQL déclare également que:

Nous avons l’intention de mettre en œuvre une gestion complète des types booléens, conformément à la norme SQL, dans une future version de MySQL.

Références: http://dev.mysql.com/doc/refman/5.5/en/numeric-type-overview.html

BTW: c’est juste une question de https://google.com/search?q=mysql+boolean+datatype .

Ce n’est pas drôle, ce lien, posté il y a quelques années, est devenu récursif.

BOOL et BOOLEAN sont des synonymes de TINYINT(1) . Le zéro est false , tout le rest est true . Plus d’informations ici .

C’est une solution élégante que j’apprécie beaucoup car elle utilise des octets de données nuls:

 some_flag CHAR(0) DEFAULT NULL 

Pour le définir sur true, définissez some_flag = '' et pour le définir sur false, définissez some_flag = NULL .

Ensuite, pour tester la valeur true, vérifiez si some_flag IS NOT NULL et, pour tester la valeur false, vérifiez si some_flag IS NULL .

(Cette méthode est décrite dans «MySQL haute performance: optimisation, sauvegardes, réplication, etc.» par Jon Warren Lentz, Baron Schwartz et Arjen Lentz.)

Cette question a été répondue mais je pensais que je mettrais 0,02 $. J’utilise souvent un CHAR (0), où ” == true et NULL == false.

De mysql docs

CHAR (0) est également très utile lorsque vous avez besoin d’une colonne qui ne peut prendre que deux valeurs: Une colonne définie comme CHAR (0) NULL n’occupe qu’un seul bit et ne peut prendre que les valeurs NULL et ” (la chaîne vide) .

Si vous utilisez le type BOOLEAN, cela correspond à TINYINT (1). C’est mieux si vous voulez utiliser du SQL standardisé et que cela ne vous dérange pas que le champ puisse contenir une valeur hors de scope (fondamentalement, tout ce qui n’est pas 0 sera “true”).

ENUM (‘False’, ‘True’) vous permettra d’utiliser les chaînes dans votre SQL, et MySQL stockera le champ en interne sous la forme d’un entier où ‘False’ = 0 et ‘True’ = 1 en fonction de l’ordre spécifié par Enum .

En MySQL 5+, vous pouvez utiliser un champ BIT (1) pour indiquer un type numérique à 1 bit. Je ne crois pas que cela utilise moins d’espace dans le stockage, mais vous permet à nouveau de limiter les valeurs possibles à 1 ou 0.

Tout ce qui précède utilisera à peu près la même quantité de stockage, il est donc préférable de choisir celui qui vous convient le mieux.

J’utilise TINYINT (1) pour stocker des valeurs booléennes dans Mysql.

Je ne sais pas s’il y a un avantage à l’utiliser … Mais si je ne me trompe pas, mysql peut stocker des booléens (BOOL) et les stocker sous forme de tinyint (1)

http://dev.mysql.com/doc/refman/5.0/en/other-vendor-data-types.html

Le bit n’est avantageux que sur les différentes options d’octet (tinyint, enum, char (1)) si vous avez beaucoup de champs booléens. Un champ de bit occupe toujours un octet complet. Les champs de deux bits entrent dans ce même octet. Trois, quatre, cinq, six, sept, huit. Après quoi, ils commencent à remplir le prochain octet. En fin de compte, les économies sont si minimes que vous devez vous concentrer sur des milliers d’optimisations. Si vous ne gérez pas une énorme quantité de données, ces quelques octets ne vont pas vous donner beaucoup. Si vous utilisez bit avec PHP, vous devez saisir les valeurs entrant et sortant.

Tant que MySQL n’a pas implémenté un type de données bit, si votre traitement est réellement sollicité pour de l’espace et / ou du temps, comme pour les transactions à volume élevé, créez un champ bit_flags appelé bit_flags pour toutes vos variables booléennes et bit_flags le bit booléen souhaité Requête SQL

Par exemple, si votre bit le plus à gauche représente votre champ booléen et que les 7 bits les plus à droite ne représentent rien, votre champ bit_flags sera égal à 128 (binary 10000000). Masquez (cachez) les sept bits les plus à droite (en utilisant l’opérateur binary) et déplacez le septième bit de sept espaces vers la droite pour finir avec 00000001. Maintenant, le nombre entier (qui, dans ce cas, est 1) est votre valeur.

 SELECT (t.bit_flags & 128) >> 7 AS myBool FROM myTable t; if bit_flags = 128 ==> 1 (true) if bit_flags = 0 ==> 0 (false) 

Vous pouvez exécuter des instructions comme celles-ci pendant que vous testez

 SELECT (128 & 128) >> 7; SELECT (0 & 128) >> 7; 

etc.

Comme vous avez 8 bits, vous avez potentiellement 8 variables booléennes d’un octet. Certains futurs programmeurs utiliseront invariablement les sept bits suivants, vous devez donc masquer. Ne vous contentez pas de changer, ou vous créerez l’enfer pour vous-même et les autres à l’avenir. Assurez-vous que MySQL effectue votre masquage et son déplacement – cela sera beaucoup plus rapide que si le langage de script Web (PHP, ASP, etc.) le faisait. Aussi, assurez-vous de placer un commentaire dans le champ commentaire MySQL pour votre champ bit_flags .

Vous trouverez ces sites utiles lors de la mise en œuvre de cette méthode:

• MySQL – Fonctions et opérateurs Bit
• Outil de conversion décimal / binary

J’en ai eu marre d’essayer d’obtenir des zéros, NULLS, et de faire le tour d’une boucle de valeurs PHP, MySql et POST, donc j’utilise simplement Yes et No.

Cela fonctionne parfaitement et n’a besoin d’aucun traitement spécial qui n’est pas évident et facile à faire.

En référence à ce lien, le type de données booléen dans Mysql , en fonction de l’utilisation de l’application, si l’on veut seulement stocker 0 ou 1, bit (1) est le meilleur choix.

Après avoir lu les réponses ici, j’ai décidé d’utiliser le bit(1) et oui, c’est mieux dans l’espace / temps, MAIS après quelques temps j’ai changé d’avis et je ne l’utiliserai plus jamais. Cela compliquait beaucoup mon développement en utilisant des instructions préparées, des bibliothèques, etc.

Depuis lors, j’utilise toujours tinyint(1) , semble assez bon.