Wie speichert ihr boolsche Werte in der DB?

[Codehunter]

Moin!

Ich mach mir immer wieder einen Kopf über die Frage, wie ich boolsche Werte am besten in einer DB-Tabelle speichere mit Blick auf Indizierbarkeit, Performance und lesbaren Delphi-Code. Einen dedizierten Bool-Typ gibt es bei MariaDB (MySQL) ja nicht.

Drei Varianten fallen mir ein:

Delphi-Quellcode:

BoolVar:= (Fields.FieldByName('TheName').AsInteger > 0); { INT(1) }
BoolVar:= (Fields.FieldByName('TheName').AsString <> '0'); { ENUM('0','1') }
BoolVar:= (Fields.FieldByName('TheName').AsInteger > 0); { TINYINT(1) }

Alle drei Varianten werden innerhalb der DB als Integer abgebildet und lassen sich indizieren.

Daneben gäbe es noch den Feldtyp BIT(1), wobei ich keine Ahnung habe wie der intern abgebildet wird in der DB.

Darum mal die Frage in die Runde: Wie macht ihr das so?

Grüße
Cody

[Jumpy]

Oft wird das ja so gemacht, das ein Wert True entspricht und alles andere ist False bzw. umgekehrt, also:

0 oder 1 oder -1 = True, alles andere False

bzw.

0 oder 1 oder -1 = False, alles andere True


Ich kann mir nie merken wie das jetzt genau war.



Nur mal generelle Frage, macht ein Index der ja über einen bool-Wert gehen soll grundsätzlich Sinn (gibt ja nur zwei Werte)?
Und falls das Sinn macht, würde ein solcher Index dann Sinn machen, wenn man das mit einem Integer nachbildet und sagt z.B. True alles <=0, False alles >0 oder so ähnlich? Denn dann können da ja alle möglichen Integer drin stehen, die Interpretation als True,False erfolgt dann ja nur in Anwendung? Was hilft da der Index?

[Codehunter]

Sagen wir mal so: In der Praxis macht sich ein Index über die "Pseudo-Bool-Felder" bemerkbar wenn ich eine WHERE-Klausel auf dieses Feld lege und eine größere Ergebnismenge bekomme. Man erkauft sich das aber mit dem Preis höherer Anforderungen der DB an das Hostsystem.

In meinem Fall speichere ich die Bool-Werte ja alle selber und kann da für mich festlegen, dass '0'=FALSE und '1'=TRUE ist. Zur Sicherheit mache ich aber (X<>'0')=TRUE.

[jobo]

Worauf willst Du denn mit der Frage hinaus?
Performance? Ressourcenverbrauch? ..?
Das Thema Indizierung bspw. ist ein mageres Feld by Boolean Werten.
Verwendet man normale Indizes, ergibt sich kaum ein Nutzen, da die Selektivität mehr oder weniger = 0 ist.
1 Mio Datensätze mit einem gleichverteilten Anteil von Booleanwerten ergeben als Selektionskriterium 500T Sätze True und 500T False. Das ergibt in der Praxis dann trotzdem einen Fullscan und damit keinen Performancegewinn, wohl aber Overhead bei der Indexverwaltung, nämlich Speicherplatz und Kosten bei Insert/Delete.
Wichtiger scheint mir in dem Bereich eine einheitliche Handhabung, ideal systemübergreifend. Dann nimmt man sich aber u.U. wieder die Möglichkeit proprietäre Verfahren einzelner Hersteller nutzbringend einzusetzen.

[Blup]

Im Interbase habe ich für Boolean eine Domain angelegt und den Feldern zugewiesen:

Code:

CREATE DOMAIN DBOOLEAN AS SMALLINT DEFAULT 0 NOT NULL CHECK (value in (0,1))

Damit sind nur die Werte 0 oder 1 möglich.

Ein Index auf Boolean-Felder macht nur Sinn, wenn die Gesamtmenge der auszuwertenden Daten damit wirklich erheblich eingeschränkt wird.
z.B.
Die Tabelle enthält 10000 Datensätze, davon 100 neue Datensätze (mit einem Boolean-Feld gekennzeichnet), die weiter verarbeitet werden müssen.
Hier ist es aber wahrscheinlich sinnvoller auf das Boolean-Feld zu verzichten und dafür eine weitere Tabelle anzulegen, in der nur die ID der 100 Datensätze gespeichert wird.
Für beliebig viele unterschiedliche Boolean-Felder müsste man diese Tabelle um ein Feld TYP ergänzen.

[joachimd]

in einer Online-Vorlesung zu In-Memory Datenbanken am HPI Potsdam hat Hasso Plattner (SAP) zu diesem Thema referiert und präferiert die Lösung, statt eines Status (true/false) lieber einen Zeitstempel zu speichern. Dann hat man zusätzlich noch die Information, wann sich der Status geändert hat. Verbunden mit einem INSERT ONLY (=>http://joachimduerr.blogspot.de/2013...sert-only.html) Konzept erhält man eine komplette Historie des Datensatzes.

[p80286]

Nun ganz so platt ist das Beispiel ja nicht, und wenn man ehrlich ist, dann wird über das vorhandensein eines Datums ein Bool-Wert erzeugt. Wobei das Konzept für Daten mit einem zeitlichen Gültigkeitsbereich durchaus seinen Reiz hat.

Gruß
K-H

[Jumpy]

Zitat:

Zitat von joachimd (Beitrag 1252490)

in einer Online-Vorlesung zu In-Memory Datenbanken am HPI Potsdam hat Hasso Plattner (SAP) zu diesem Thema referiert und präferiert die Lösung, statt eines Status (true/false) lieber einen Zeitstempel zu speichern. Dann hat man zusätzlich noch die Information, wann sich der Status geändert hat. Verbunden mit einem INSERT ONLY (=>http://joachimduerr.blogspot.de/2013...sert-only.html) Konzept erhält man eine komplette Historie des Datensatzes.

Nur das ich das richtig verstehe: Das bezieht sich auf den Post von Blup vorher, über den möglichen Verwendungszweck des boolschen Feldes, oder? Nicht auf boolsche Felder generell?

P.S.: Hab mir auch mal deinen Blogeintrag durchgelesen. Das erinnert mich doch sehr an die Historienverwaltung, in einer Payroll-Software um die herum wir viel arbeiten.

[joachimd]

Zitat:

Zitat von Jumpy (Beitrag 1252494)

Nur das ich das richtig verstehe: Das bezieht sich auf den Post von Blup vorher, über den möglichen Verwendungszweck des boolschen Feldes, oder? Nicht auf boolsche Felder generell?

Eigentlich schon auf boolsche Felder generell. Die Kernaussage ist, dass Boolen-Felder (true/false, 1/0, ...) eigentlich nicht verwendet werden sollen, da man mit einem Zeitstempel statt Boolean noch zusätzliche Information vorhalten kann. Zeitstempel=NULL heisst dann eben FALSE, Zeitstempel<>FALSE ist TRUE mit Zusatz-Info.

[Mavarik]

hmm

Bei SQLite auf iOS & Android habe ich mir eine Classe erzeugt die alle Bool-Werte kapselt und in einem einzigen String speichert. (weniger Speicher)

Nach dem Motto "JJJNNNJJJNJNJNJNJNJNJJJJJJ"

Die Felddefinition erzeugt ein Dictionary mit den Feldnamen und kennt die Position im String.

Sehr praktisch.

Checkbox.Checked := MySQLite.GetBool('Einstellung1');

Mavarik