Wie speichert ihr boolsche Werte in der DB?

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

[Sir Rufo]

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

Darum ging es bei dieser Betrachtung zwar nicht, aber den gesamten Status (wieviel und komplett) zur Rechnung in einer separaten Tabelle und Update per Trigger.

[sx2008]

Zitat von Sir Rufo:

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

Wie soll dann ein Kunde gesperrt werden weil der Rechnungsempfänger z.B. insolvent ist?
Manche Versender geben Kunden mit negativer Schufaauskunft auch eine eingeschränkte Kundensperre und verschicken z.B. nur per Nachnahme.
Ein Sperrfeld in der Kundentabelle ist absolut sinnvoll und muss mehr Informationen tragen können als nur True oder False.

[DateTimeError]

Sorry, wenn ich mich hier als völlig DB.Außenstehender einmische:

Wer ein "Falsch" nicht als Nil/Null/0 wegschreibt, sollte seine Existenzbeschreibung überdenken.

Ob man ein plus1 oder minus1 als "Zutreffend/Richtig/Wahr" interpretiert, scheint mir im Auge des *perversen* Betrachters zu liegen:

Frage: "Sammeln Sie Kinderpornos?"
Antwort: "Nie und Nimmer!"
Also minus1 statt null?

Alles klar?

[Sir Rufo]

Zitat von sx2008:

Zitat von Sir Rufo:

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

Wie soll dann ein Kunde gesperrt werden weil der Rechnungsempfänger z.B. insolvent ist?
Manche Versender geben Kunden mit negativer Schufaauskunft auch eine eingeschränkte Kundensperre und verschicken z.B. nur per Nachnahme.
Ein Sperrfeld in der Kundentabelle ist absolut sinnvoll und muss mehr Informationen tragen können als nur True oder False.

Indem man die Kundensperre entsprechend der Meta-Informationen interpretiert?
Insolvenz, Schufa, etc. -> Bar, Nachnahme
Doofmann -> gar nicht

In der Kundentabelle selber fehlt auch die Möglichkeit einer reinen Sperr-Historie.
Irgendwie machbar, aber umständlich und gehört irgendwie nicht so zusammen wie die Firmierung und die Handelsregister-Nummer.