web-dev-qa-db-fra.com

Tinyint vs Bit?

Je ne veux pas parler d'une guerre de religion ici, mais il semble y avoir deux écoles de pensée sur la façon de représenter les valeurs booléennes dans une base de données. Certains disent que bit est le type de données approprié, tandis que d'autres soutiennent que tinyint est préférable.

Les seules différences que je connaisse sont les suivantes:

  • bit: la taille de stockage est de 1 bit, les valeurs possibles sont 0 ou 1
  • tinyint: la taille de stockage est de 1 octet, les valeurs possibles sont comprises entre 0 et 255

Quel type de données est préférable lorsque vous devez représenter des valeurs booléennes? tinyint vaut-il la surcharge supplémentaire "au cas où" vous auriez besoin de valeurs> 1?

sqlmysqlsql-servertypes
71
Seibar

Lorsque vous ajoutez une colonne de bits à votre table, celle-ci occupe un octet entier dans chaque enregistrement, pas un seul bit. Lorsque vous ajoutez une deuxième colonne de bits, elle sera stockée dans le même octet. La colonne de neuvième bit nécessitera un deuxième octet de stockage. Les tables avec une colonne de 1 bit n'apporteront aucun avantage en termes de stockage.

Tinyint et bit peuvent tous deux être utilisés, j'ai utilisé les deux avec succès et je n’ai aucune préférence marquée.

81
ScottS

Bit ... sauf si vous êtes du clan "vrai/faux/fichier non trouvé"

Au cas où vous ne receviez pas la référence ...

Et dans le cas de Linq2SQL, bit fonctionne avec true/false, ce qui facilite la programmation. Il y a des avantages aux deux.

Et il y a aussi la maintenance de programmation à considérer. Que se passe-t-il si vous (ou un stagiaire stagiaire) utilisez un 2, 3, 25, 41, 167, 200, etc.? Où est-ce documenté? Les bits sont auto-documentés et universels.

18
Mike Robinson

J'utilise des bits lorsque cela convient. Hormis le fait qu'il soit sémantiquement du type correct (compte sémantique!), Plusieurs champs de bits (jusqu'à 8) d'une même ligne (sur SQL Server, de toute façon) peuvent être consolidés dans un seul octet de stockage. Après le huitième, un octet supplémentaire est nécessaire pour le prochain 8, et ainsi de suite.

Références:

14
John Rudy

Pour les utilisateurs de MySQL - Pourquoi ne pas utiliser les colonnes BIT dans MySQL

5
armandino

Un article précédent de StackOverflow: Quelle est la différence entre BIT et TINYINT dans MySQL?

Lors de l'ajout d'une nouvelle colonne "BOOL", MySQL utilise en réalité TINYINT.

Je me contenterais de rester avec BOOL (alias TINYINT) et de passer à autre chose.

3
Matt

Toutes ces discussions théoriques sont excellentes, mais en réalité, du moins si vous utilisez MySQL et vraiment pour SQLServer également, 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 rester avec BOOL ou BOOLEAN, qui est stocké sous le nom TINYINT (1). Même si MySQL Workbench et l'administrateur MySQL affichent le type de données BIT, ce n'est pas Nice (c'est un petit symbole pour les données binaires). Soyez donc pratique et évitez les tracas (et malheureusement, je parle d'expérience).

2
Sheldmandu

Boolean, par définition, n'autorise que deux valeurs. Pourquoi auriez-vous besoin de plus qu'un seul bit pour cela? si vous avez besoin d'une logique à trois états (ou plus), utilisez un type de données plus grand, mais je collerais (et ferais) des champs de bits pour la logique booléenne standard.

2
tvanfosson

J'utilise bit car cela me permet d'éviter de devoir utiliser une contrainte de vérification et parce que mon ORM convertira automatiquement bit en un booléen nullable (C #), ce que j'apprécie beaucoup une fois.

2
RedFilter

Je viens d'essayer de regrouper sur bit (SQL Server 2k5) et cela a fonctionné pour moi. J'aime utiliser le type de données correct pour l'application. Si c'est un champ vrai/faux, alors c'est ce que j'utilise ... 

1
Rob

Je ne pense pas l'avoir vu mentionné ci-dessus, mais il y a le problème de l'impossibilité d'agréger les colonnes de BIT (par exemple, MIN, MAX et surtout SUM). Je viens de tester en 2008 et le problème est toujours là. C’est la principale raison pour laquelle j’ai utilisé tinyint ces derniers temps (l’autre raison pour laquelle j’ai aimé l’échelle de tinyint) est toujours pénible lorsque votre indicateur de bit "deux valeurs" a soudainement besoin de plus de valeurs possibles.

1
saldag

Nous construisons toutes nos tables avec un champ "vector" int. Nous utilisons ensuite ce champ comme une collection de 32 bits que nous pouvons affecter à n’importe quel but. (Utilisation potentielle d'un groupe de bits pour un ensemble d'états). Nous évite d'avoir à continuer à ajouter des champs de drapeau si nous oublions.

0
Joe

@Kevin: Je pense que vous pouvez utiliser group by sur des champs de bits (SQL Server 2005):

declare @t table (
    descr varchar(10),
    myBit1 bit, 
    myBit2 bit
)
insert into @t values ('test1', 0, 1)
insert into @t values ('test2', 1, 0)
insert into @t values ('test3', 1, 1)
insert into @t values ('test4', 0, 0)

select myBit1, count(myBit1) from @t group by myBit1
select myBit2, count(myBit1) from @t group by myBit2

Résultats:

myBit1 
------ -----------
0      2
1      2

myBit2 
------ -----------
0      2
1      2
0
Seibar

TinyInt est ma préférence. Ensuite, lorsque vous effectuez des comptes agrégés dans le champ, vous n'avez pas à le lancer. En outre, certains langages frontaux interprètent Bit de manière différente des autres et utiliser un TinyInt rend les contrôles de validation universels pour tous les langages frontaux.

0
Gregory Hart