Wie speichert ihr boolsche Werte in der DB?

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

[FBrust]

Hallo,

Perlsau meint vermutlich, dass Smallint in Verbindung mit Domäne in Firebird über IBDAC nicht funktioniert.

Als normale Spalte vom Typ "Smallint", in der 0 oder 1/-1 gespeichert werden, gibt es keine Probleme.


Gruß
Frank

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

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

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

[Perlsau]

Zitat von FBrust:

Perlsau meint vermutlich, dass Smallint in Verbindung mit Domäne in Firebird über IBDAC nicht funktioniert. Als normale Spalte vom Typ "Smallint", in der 0 oder 1/-1 gespeichert werden, gibt es keine Probleme.

Genau!

17.13.1.8.2.2 BooleanDomainFields Property
Used to create TBooleanField for fields that have domain of the integer data type, and the domain name contains 'BOOLEAN'.
Class: TIBCDataSetOptions
Syntax: property BooleanDomainFields: boolean default False;
Remarks: If the BooleanDomainFields property is set to True, TBooleanField objects are created for fields that have domain of the integer data type, and the domain name contains 'BOOLEAN'.

[mirage228]

Da Du ja MySQL bzw. MariaDB verwendest, kann ich Dir vllt. sagen wie ich das bei MySQL 5.1 mit UniDAC handhabe.

Ich erstelle meine DB-Modelle mit MySQL Workbench. Da kannst Du durchaus "BOOLEAN"-Typen anlegen. Die werden in der Datenbank auf TINYINT(1) Felder gemappt. Das finde ich legitim und habe das bisher immer so verwendet. Wenn Du BIT(1) verwendest ist das Anzeigen der Werte schwierig, da Bitwerte nicht-druckbare Zeichen sind.

Mit UniDAC sollte auch ein Field.AsBoolean kein Problem sein. EnableBoolean bei TUniQuery ist bei MySQL standardmäßig auf True, womit TINYINT(1) als TBooleanField angesprochen werden kann.

Viele Grüße