it-swarm.com.de

Tinyint vs Bit?

Ich möchte hier keinen Religionskrieg anstacheln, aber es scheint zwei Gedankengänge zu geben, wie man boolsche Werte in einer Datenbank darstellt. Einige sagen, bit sei der passende Datentyp, während andere behaupten, tinyint sei besser.

Die einzigen Unterschiede, die mir bekannt sind, sind folgende:

  • bit: Speichergröße ist 1 Bit, mögliche Werte sind 0 oder 1
  • tinyint: Speichergröße ist 1 Byte, mögliche Werte sind 0-255

Welcher Datentyp ist besser, wenn Sie boolesche Werte darstellen müssen? Ist tinyint den zusätzlichen Aufwand wert, "nur für den Fall", dass Sie Werte> 1 benötigen?

71
Seibar

Wenn Sie Ihrer Tabelle eine Bit-Spalte hinzufügen, belegt diese in jedem Datensatz ein ganzes Byte, nicht nur ein einzelnes Bit. Wenn Sie eine zweite Bitspalte hinzufügen, wird sie in demselben Byte gespeichert. Die neunte Bit-Spalte erfordert ein zweites Byte Speicher. Tabellen mit 1-Bit-Spalten erhalten keinen Speichervorteil.

Tinyint und Bit können beide zum Laufen gebracht werden, ich habe beide erfolgreich eingesetzt und habe keine starken Vorlieben.

81
ScottS

Bit ... es sei denn, Sie gehören zum Clan "true/false/file not found"

Falls Sie die Referenz nicht erhalten haben ...

Im Fall von Linq2SQL arbeitet bit mit true/false, was die Programmierung erleichtert. Beides hat Vorteile.

Und es gibt auch Programmierwartungen, die zu berücksichtigen sind. Was passiert, wenn Sie (oder ein Junior-Programmierer) eine 2, 3, 25, 41, 167, 200 usw. verwenden? Wo ist das dokumentiert? Bits sind selbstdokumentierend und ziemlich universell.

18
Mike Robinson

Ich verwende bei Bedarf Bits. Abgesehen davon, dass es sich um einen semantisch richtigen Typ (Semantikanzahl!) Handelt, können mehrere Bitfelder (bis zu 8) in einer einzelnen Zeile (auf SQL Server jedenfalls) in einem einzigen Speicherbyte konsolidiert werden. Nach dem achten wird für die nächsten 8 ein zusätzliches Byte benötigt, und so weiter.

Verweise:

14
John Rudy
5
armandino

Ein vorheriger StackOverflow-Beitrag: Was ist der Unterschied zwischen BIT und TINYINT in MySQL?

Beim Hinzufügen einer neuen "BOOL" -Spalte verwendet MySQL TINYINT.

Ich würde einfach bei BOOL (aka TINYINT) bleiben und mit dem Leben fortfahren.

3
Matt

Alle diese theoretischen Diskussionen sind großartig, aber in der Realität, zumindest wenn Sie MySQL und wirklich auch für SQLServer verwenden, sollten Sie für Ihre Booleschen nicht-binäre Daten verwenden gibt die Daten aus, fragt ab und so weiter. Dies ist besonders wichtig, wenn Sie versuchen, Interoperabilität zwischen MySQL und SQLServer zu erreichen (d. H. Sie synchronisieren Daten zwischen den beiden), da die Handhabung des BIT-Datentyps in beiden Fällen unterschiedlich ist. SO In der Praxis haben Sie viel weniger Ärger, wenn Sie sich an einen numerischen Datentyp halten. Ich würde es für MySQL empfehlen, bei BOOL oder BOOLEAN zu bleiben, das als TINYINT (1) gespeichert wird. Auch die Art und Weise, wie MySQL Workbench und MySQL Administrator den BIT-Datentyp anzeigen, ist nicht Nizza (es ist ein kleines Symbol für binäre Daten). Seien Sie also praktisch und sparen Sie sich den Ärger (und leider spreche ich aus Erfahrung).

2
Sheldmandu

Zero Space for False

Wie auch immer Sie sich entscheiden, Sie können statt 0 auf NULL setzen, und es wird kein zusätzlicher Speicherplatz benötigt (da die Datenbank fast immer ein NULL-Flag für jedes Feld jeder Zeile hat und nur dort sitzt; more Infos hier ). Wenn Sie außerdem sicherstellen, dass der Standardwert/der wahrscheinlichste Wert false ist, sparen Sie noch mehr Speicherplatz!

Etwas Platz für wahr

Der Wert, der true darstellt, erfordert den durch den Feldtyp definierten Platz. Die Verwendung von BIT spart nur Speicherplatz, wenn eine Tabelle mehrere solcher Spalten enthält, da sie ein Byte pro 8 Felder verwendet (im Gegensatz zu TINYINT, das ein Byte pro Feld verwendet).

TINYINT bietet den Vorteil, dass Sie eine 8-wertige Bitmaske anpassen können, ohne sich um das Verwalten mehrerer zusätzlicher Spalten kümmern zu müssen. Die Suche ist theoretisch schneller (ein einzelnes ganzzahliges Feld gegenüber mehreren Bitfeldern). Es gibt jedoch einige Nachteile, wie z. B. langsamere Reihenfolge, ausgefallene Kreuzindizierungen und das Fehlen von Feldnamen. Was für mich der größte Verlust ist; Ihre Datenbank würde eine externe Dokumentation erfordern, um festzustellen, welche Bits in welchen Bitmasken verwendet wurden.

Vermeiden Sie auf jeden Fall die Versuchung, TEXT-Felder zu verwenden, um Booleans oder Gruppen von ihnen zu speichern. Das Durchsuchen von Text ist für den Server viel mehr Arbeit, und beliebige Namensschemata wie "Ein, Aus, Aus" können die Interoperabilität beeinträchtigen.

2
Beejor

Boolean erlaubt per Definition nur zwei Werte. Warum brauchen Sie dafür mehr als nur ein bisschen? Wenn Sie eine Zustandslogik mit drei (oder mehr) Zuständen benötigen, verwenden Sie einen größeren Datentyp, aber ich würde (und mache) bei Bitfeldern für Standard-Boolesche Logik.

2
tvanfosson

Ich benutze bit, weil ich dadurch keine Prüfbeschränkung verwenden muss und weil mein ORM Bit automatisch in einen nullbaren booleschen Wert (C #) konvertiert, was ich beim Codieren sehr schätze.

2
RedFilter

Ich habe gerade versucht, auf Bit (SQL Server 2k5) zu gruppieren und es funktionierte gut für mich. Ich mag es, den richtigen Datentyp für die Anwendung zu verwenden. Wenn es ein wahres/falsches Feld ist, dann benutze ich ein bisschen ... 

1
Rob

Ich glaube nicht, dass ich es oben erwähnt gesehen habe, aber es gibt das Problem, dass BIT-Spalten nicht zusammengefasst werden können (z. B. MIN, MAX und insbesondere SUM). Ich habe gerade mit 2008 getestet und das Problem ist immer noch da. Das ist der größte Grund, warum ich tinyint in letzter Zeit verwende - das andere ist, dass ich mag, wie tinyint-Skalen - es ist immer ein Schmerz, wenn Ihre "Zwei-Wert" -Bit-Flag plötzlich mehr mögliche Werte benötigt.

1
saldag

Wir bauen alle unsere Tabellen mit einem "Vektor" -Feld. Wir verwenden dieses Feld dann als eine Sammlung von 32 Bits, die wir für jeden Zweck zuweisen können. (Potentiell Verwendung einer Gruppe von Bits für eine Reihe von Zuständen). Vermeidet, dass wir ständig Flaggenfelder hinzufügen müssen, wenn wir vergessen.

0
Joe

@Kevin: Ich glaube, Sie können group by für Bitfelder (SQL Server 2005) verwenden:

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

Ergebnisse:

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

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

TinyInt ist meine Präferenz. Wenn Sie dann aggregierte Zählungen gegen das Feld durchführen, müssen Sie es nicht umsetzen. Außerdem interpretieren einige Front-End-Sprachen ein Bit anders als andere. Durch die Verwendung eines TinyInt werden Validierungsprüfungen für alle Front-End-Sprachen universell.

0
Gregory Hart