Wie speichert ihr boolsche Werte in der DB?

[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

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

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.

[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

[Perlsau]

Nicht in allen Fällen ist es ratsam, als Repräsentant für ein Boolean-Feld die kleinste verfügbare Einheit zu nehmen. So erwarten die IbDac-Komponenten von Devart einen Integer. Mit einem SmallInt, der z.B. bei den FibPlus-Komponenten funktionierte, tritt bei Verwendung von IbDac eine Fehlermeldung auf bzw. wird dieses Feld nicht als Boolean erkannt. Der String "Boolean" muß im Feldnamen vorkommen, bei Firebird z.B.:

Code:

CREATE DOMAIN INTBOOLEAN AS
INTEGER
DEFAULT 0
NOT NULL
CHECK (VALUE IN (0,1));

COMMENT ON DOMAIN INTBOOLEAN IS 
'Boolean False oder True';

[Sir Rufo]

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

• SplashScreen aktiv ist immer ein Boolean => Entweder aktiv oder nicht aktiv
• Kundensperre aktiv ist immer ein Boolean => Entweder aktiv oder nicht aktiv

allerdings ist diese Information das Resultat von mehreren Umständen.

Also legt man diese Zusatzinformationen in eine eigene Tabelle und prüft, ob es dort Einträge gibt, und wenn ja, ob diese auf die aktuelle Situation passen.

SplashDisable

OSType

TerminalServer

Kunden

ID	Name
1	Peter
2	Paul

KundeSperren

KundeId	Grund	Seit
1	Insolvenz	01.01.2014

Das Beispiel mit den Rechnungen verhält sich ähnlich
Rechnungen

ID	KundeId	Nummer	Datum	Betrag
1	1	12345	01.01.2014	100,00
2	1	12346	02.01.2014	200,00

Zahlungen

ID	KundeId	Datum	Betrag
1	1	10.01.2014	250,00

RechnungZahlungen

RechnungId	ZahlungId	Betrag
1	1	100,00
2	1	150,00

Löscht man aus der Tabelle RechnungZahlung den Satz 2|1, dann verbleibt bei der Zahlung ein noch nicht zugeordneter Betrag von 150,00 und die Rechnung 2 ist wieder komplett offen.

Den Boolean-Wert für RechnungBezahlt bekommt man also durch die Analyse der entsprechenden Tabelle.

[Furtbichler]

Zitat von Sir Rufo:

Den Boolean-Wert für RechnungBezahlt bekommt man also durch die Analyse der entsprechenden Tabelle.

Nicht sonderlich performant (als berechnetes Feld), oder würdest Du das über einen Trigger lösen?