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