Wie speichert ihr boolsche Werte in der DB?

[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 von 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.

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 von Jumpy:

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

[Furtbichler]

SQL-Server bietet bit-Felder an, die intern als Byte abgelegt werden, allerdings so, das immer 8 bit-Felder eines Datensatzes in ein Byte passen. Man bekommt also 7 bits geschenkt, wenn man ein bit anlegt. Wieso man einen Mehrwert haben sollte, wenn ich das als Zeitstempel umsetze, erschließt sich mir nicht. Wenn ich eine Historienverwaltung brauche, lege ich sie an.

Was hab ich davon, das ich weiß, das die Option 'HatdieHosenAn' gestern um 17:30 gesetzt wurde, aber die Information 'Durchmesser des Nudelholzes' zwar auf 36cm steht (echt ne fiese Sache, so eine Ehe), aber ich dummerweise nicht weiss, wann diese doch sozusagen systemimmanente Wert von vormals 3cm hochgesetzt wurde.

Dessenungeachtet ist es schon etwas merkwürdig, beim Feldnamen 'IstNachtaktiv' einen Zeitstempel zu sehen: Bedeutet das: 'Ist nachtaktiv ab ....?' oder bis? Nee, also Ich kann mir auch von hinten durch die Brust ins Auge schießen.

Zurück zum Thema: Wenn die DB keine Bits unterstützt, dann würde ich die ansonsten kleinste Einheit nehmen, also char(1), smallint etc. Die Sache mit den Constraints ist nett, frist zwar ein wenig Performance, aber WTF, außerdem ist das dann so sauber.

Nebenbei: Ebenso wie in der Programmierung ist es häufig so, das aus zwei Zuständen rasch mehr werden... Und insofern ist ein smallint gar nicht mal so blöd. Fängt schon beim Geschlecht an. Vor 30 Jahren reichte ein Bit: IstWeiblich Ja/nein (Wir sind ja schön gequotet). Aber heutzutage benötigt man schon etwas mehr Optionen, um das Geschlecht anzugeben (Weiblich, Männlioh, weiß noch nicht, bin gerade am umbiegen, beides, weder noch, da Politiker etc.).

[Phoenix]

Zitat von joachimd:

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.

An sich ne coole Idee, geht aber leider nicht, wenn man tatsächlich einen "3-State Boolean" braucht:

• true = true
• false = false
• null = undefined / default

Und ja, es kommt in der Praxis durchaus mal vor, das man einen bool explizit noch nicht gesetzt haben darf, da der Business-Case z.B. sowohl für das Ja als auch das Nein eine bewusste Entscheidung des Users voraussetzt. Solange die nicht da ist, ist es eben undefined.