Wie speichert ihr boolsche Werte in der DB?

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

[FBrust]

Hallo,

Zitat:

Zeitstempel=NULL heisst dann eben FALSE, Zeitstempel<>FALSE ist TRUE mit Zusatz-Info.

Das bedeutet also, um ein Feld wieder auf die Information "False" zu setzen, setze ich den Inhalt auf Null? Wo ist dann die Zusatzinformation? Die hätte ich doch nur, solange das Feld auf "True" steht, also ein Zeitstempel vorhanden ist....

Mir geht es da wie DeddyH, erschließt sich mir nicht wirklich....

Ich verwende für Boole'sche Informationen Smallint-Felder mit 0 für False und 1 für True, wobei nur auf <> 0 geprüft wird (Firebird 2.5.2).

Firebird 3 soll ja Boole'sche Felder direkt unterstützen, aber bis dahin ist wohl noch lang hin.


Grüße
Frank

[joachimd]

Zitat:

Zitat von FBrust (Beitrag 1252528)

Das bedeutet also, um ein Feld wieder auf die Information "False" zu setzen, setze ich den Inhalt auf Null? Wo ist dann die Zusatzinformation? Die hätte ich doch nur, solange das Feld auf "True" steht, also ein Zeitstempel vorhanden ist....

Mir geht es da wie DeddyH, erschließt sich mir nicht wirklich....

Wenn man den Kontext mit Hasso Plattner/SAP betrachtet, dann macht es etwas mehr Sinn. Eine Rechnung ist bezahlt am ... oder offen. Dann noch ein INSERT ONLY und die Historie ist gegeben (bezahlte Rechnung plötzlich wieder unbezahlt). Ich gebe zu, das macht nicht bei jedem Boolean-Feld Sinn - aber wenn eine Zusatzinformation vorhanden ist, dann lieber so als mit zwei Feldern (bezahlt, bezahlt_am) - und lach nicht, solche Konstrukte sehe ich fast täglich;)

[p80286]

Nemen wir das Nudelholz, das ist so schön schief
id name Durchmesser durchmesser_alt_erledigt

1. Nudelholz 8 null
2. Marmor 10 10
3. Birke 12 null
4. Stahl null null

Wenn Du ein Nudelholz hast, gibt es auch einen Durchmesser (<>null), ohne Durchmesser soll es erst noch gekauft werden. Ist Durchmesser_alt_erledigt belegt, dann gibt es das Nudelholz nicht mehr (frag Furtbichler wo's ist)

Wenn man dafür dann ein Datumsfeld/Timestamp nimmt, dann weiß man von wann bis wann man das Nudelholz gehabt hat.
Oder anders herum: IchbinNudelholzeigentümer:=(durchmesser <> null) and (durchmesser_alt_erledigt = null)
ich_hatte_mal_EIN_nudelholz:=(durchmesser<>null) and (durchmesser_alt_erledigt <> null)


Gruß
K-H

[Olli73]

Zitat:

Zitat von joachimd (Beitrag 1252537)

Eine Rechnung ist bezahlt am ... oder offen. Dann noch ein INSERT ONLY und die Historie ist gegeben (bezahlte Rechnung plötzlich wieder unbezahlt).

Und dann wird festgestellt, dass eine Zahlung falsch zugeordnet wurde und umgebucht werden muss ;)

Da wäre ein Test "sum(alleBuchungsbeträge) = 0" besser, und wenn es mehrere Teilzahlungen waren, braucht man sowieso bei jeder Zahlung einen Timestamp.

[Phoenix]

Zitat:

Zitat von joachimd (Beitrag 1252495)

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.

[sx2008]

Also nach meinen Erfahrungen nach kommt es recht häufig vor, dass später weitere Zustände ausser True und False benötigt werden.
Deshalb verwende ich immer meistens ein BYTE (0..255) als Booleanfeld.
Beispiel 1:
Splashscreen_aktive: True oder False.
Später fällt mir dann ein, dass ich den Splashscreen nicht aktivieren möchte, wenn die Anwendung auf einem Terminalserver läuft; es soll aber einstellbar sein. Und schon sind es 3 Zustände...
Beispiel 2:
Kundensperre (z.B. weil der Kunde im Zahlungsrückstand ist).
Könnte man ja meinen dass True oder False ausreichend sind.
Später möchte man aber genauer wissen weshalb der Kunde gesperrt ist (Insolvent, Zahlungsrückstand, Gerichtsverfahren anhängig, ...) und schon braucht man wieder mehr Zustände.

Deshalb jedes Booleanfeld genau überprüfen und vorrausplanen ob nicht ein Bytefeld besser passt.

[FBrust]

Hallo,

für mich ergibt das nur Sinn, wenn sichergestellt ist, dass das Feld mit dem Timestamp nie wieder geändert werden kann (da ja sonst die Information verlorenginge), insofern hat joachimd das schon richtiggestellt.

Wenn das Feld wieder geändert werden kann, muss man eben die bisher bekannten Datentypen verwenden (smallint, char, usw. usf).

Gruß
Frank