Wie speichert ihr boolsche Werte in der DB?

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

[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 von FBrust:

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

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