Wie speichert ihr boolsche Werte in der DB?

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

[Bummi]

@Furtbichler sorry für OT, aber bei Deiner Antwort merkt man dass es Frühling wird ...

[DeddyH]

Das Timestamp-Konzept leuchtet mir allerdings auch nicht wirklich ein, vor allem, wenn NULL als false interpretiert werden soll. Auf diese Weise kann man dann zwar ermitteln, wann der Status zu true gewechselt ist, aber nicht andersherum, da ja dann NULL im Feld steht. Ich selbst mache das meist so wie von Blup skizziert, indem ich eine Boolean-Domäne anlege, die benutzt dann den kleinsten ganzzahligen Typen, den die DB anbietet.

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