Quelle est la différence entre BIT et TINYINT dans MySQL?
Dans quels cas utiliseriez-vous lequel? Y a-t-il une grande différence? Lequel des moteurs de persistance que j'utilise généralement pour stocker des booléens?
Un TINYINT est une valeur entière de 8 bits, un champ BIT peut stocker entre 1 bit, BIT (1) et 64 bits, BIT (64). Pour une valeur booléenne, BIT (1) est assez commun.
De aperçu des types numériques ;
BIT [(M)]
Un type de champ de bits. M indique le nombre de bits par valeur, compris entre 1 et 64. La valeur par défaut est 1 si M est omis.
Ce type de données a été ajouté dans MySQL 5.0.3 pour MyISAM et étendu dans la version 5.0.5 à MEMORY, InnoDB, BDB et NDBCLUSTER. Avant la version 5.0.3, BIT est un synonyme de TINYINT (1).
TINYINT [(M)] [UNSIGNED] [ZEROFILL]
Un très petit entier. La plage signée est comprise entre -128 et 127. La plage non signée est comprise entre 0 et 255.
En outre, considérez ceci;
BOOL, BOOLEAN
Ces types sont des synonymes de TINYINT (1). Une valeur de zéro est considérée comme fausse. Les valeurs non nulles sont considérées comme vraies.
Toutes ces discussions théoriques sont excellentes, mais en réalité, du moins si vous utilisez MySQL et vraiment pour SQLServer, il est préférable de conserver des données non binaires pour vos booléens pour la simple raison qu'il est plus facile de travailler avec. 'sortie des données, interrogation et ainsi de suite. Cela est particulièrement important si vous essayez d’obtenir l’interopérabilité entre MySQL et SQLServer (c’est-à-dire que vous synchronisez des données entre les deux), car le traitement du type de données BIT est différent dans les deux cas. SO en pratique, vous aurez beaucoup moins de tracas si vous vous en tenez à un type de données numérique. Je recommanderais à MySQL de s'en tenir à BOOL ou BOOLEAN, qui est stocké sous la forme TINYINT (1). Même le chemin MySQL Workbench et l'administrateur MySQL affichent que le type de données BIT n'est pas Nice (c'est un petit symbole pour des données binaires). Soyez donc pratique et évitez les tracas (et malheureusement, je parle d'expérience).
BIT ne doit autoriser que 0 et 1 (et NULL si le champ n'est pas défini comme NOT NULL). TINYINT (1) autorise toutes les valeurs pouvant être stockées dans un seul octet, -128..127 ou 0..255, qu’elles soient non signées ou non (le 1 indique que vous avez l’intention d’utiliser un seul chiffre, mais cela ne se produit pas. ne vous empêche pas de stocker une valeur supérieure).
Pour les versions antérieures à 5.0.3, BIT est interprété comme TINYINT (1), donc il y a une différence de non.
BIT a une sémantique "c'est une booléenne", et certaines applications considèrent TINYINT (1) de la même manière (en raison de la façon dont MySQL le traitait), ainsi les applications peuvent formater la colonne sous forme de case à cocher si elles vérifient le type. et décider d'un format basé sur cela.
Peut-être tort mais:
Tinyint est un entier compris entre 0 et 255
le bit est 1 ou 0
C'est donc pour moi un peu le choix des booléens
D'après mon expérience, je vous dis que BIT a des problèmes avec les types de systèmes d'exploitation Linux (Ubuntu par exemple). J'ai développé ma base de données sous Windows et après avoir tout déployé sous Linux, des problèmes se posaient lors de requêtes insérées ou sélectionnées dans des tables contenant BIT DATA TYPE.
Le bit n'est pas sûr pour l'instant. J'ai changé pour tinyint (1) et j'ai parfaitement fonctionné. Je veux dire que vous n'avez besoin que d'une valeur pour différencier si c'est 1 ou 0 et tinyint (1) c'est bon pour ça