Dans quels cas utiliseriez-vous lequel? Y a-t-il une grande différence? Lequel j'utilise généralement par les moteurs de persistance pour stocker des booléens?
Dans quels cas utiliseriez-vous lequel? Y a-t-il une grande différence? Lequel j'utilise généralement par les moteurs de persistance pour stocker des booléens?
Réponses:
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 courant.
De Vue d'ensemble des types numériques ;
BIT [(M)]
Un type de champ de bits. M indique le nombre de bits par valeur, de 1 à 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 5.0.5 à MEMORY, InnoDB, BDB et NDBCLUSTER. Avant 5.0.3, BIT est un synonyme de TINYINT (1).
TINYINT [(M)] [UNSIGNED] [ZEROFILL]
Un tout petit entier. La plage signée est comprise entre -128 et 127. La plage non signée est comprise entre 0 et 255.
Considérez également ceci;
BOOL, BOOLÉEN
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.
booleancela prendra un octet même si c'est vraiment juste un peu, donc un BIT (1) est meilleur après la v5.0.3?
BOOL/ BOOLEANsoient des alias pour TINYINT(1)au lieu de BIT. Bien sûr, ils finissent tous par occuper un octet entier, mais sémantiquement, ce BITserait beaucoup plus approprié.
Toutes ces discussions théoriques sont excellentes, mais en réalité, au moins si vous utilisez MySQL et vraiment aussi pour SQLServer, il est préférable de s'en tenir aux données non binaires pour vos booléens pour la simple raison qu'il est plus facile de travailler avec lorsque vous 'sortez les données, interrogez et ainsi de suite. C'est particulièrement important si vous essayez d'atteindre l'interopérabilité entre MySQL et SQLServer (c'est-à-dire que vous synchronisez les données entre les deux), car la gestion du type de données BIT est différente dans les deux. Ainsi, dans la 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é en tant que TINYINT (1). Même la façon dont MySQL Workbench et MySQL Administrator affichent le type de données BIT n'est pas agréable (c'est un petit symbole pour les données binaires).
BIT ne doit autoriser que 0 et 1 (et NULL, si le champ n'est pas défini comme NOT NULL). TINYINT (1) autorise toute valeur qui peut être stockée dans un seul octet, -128..127 ou 0..255 selon qu'elle n'est pas signée ou non (le 1 indique que vous avez l'intention de n'utiliser qu'un seul chiffre, mais il le fait ne vous empêche pas de stocker une valeur plus grande).
Pour les versions antérieures à 5.0.3, BIT est interprété comme TINYINT (1), il n'y a donc aucune différence.
BIT a une sémantique «ceci est un booléen», et certaines applications considéreront TINYINT (1) de la même manière (en raison de la façon dont MySQL le traitait), de sorte que les applications peuvent formater la colonne comme une case à cocher si elles vérifient le type et décidez d'un format basé sur cela.
Cela peut être faux mais:
Tinyint est un entier compris entre 0 et 255
le bit vaut 1 ou 0
Par conséquent, pour moi, le choix des booléens est un peu
D'après mon expérience, je vous dis que BIT a des problèmes sur les types d'OS Linux (Ubuntu par exemple). J'ai développé ma base de données sur Windows et après avoir tout déployé sur Linux, j'ai eu des problèmes avec les requêtes insérées ou sélectionnées à partir de tables contenant le TYPE DE DONNÉES BIT.
Bit n'est pas sûr pour le moment. Je suis passé à tinyint (1) et j'ai parfaitement fonctionné. Je veux dire que vous avez seulement besoin d'une valeur pour différencier si c'est 1 ou 0 et tinyint (1) c'est ok pour ça