Wie stellst du booleans in MySQL dar?

[AmicaNoctis]

Hallo Slava,

deine Definition von set ist leider schlichtweg falsch. Set (engl. für "Menge") ist für Mengen gedacht, also beliebige Kombinationen der zugelassenen Elemente. Das set-Feld auf '' oder 0 zu setzen, entspricht mathematisch der leeren Menge und ist weder ein unsauberes noch unlogisches Verhalten.

MySQL sagt dazu übrigens

the SET datatype allows you to store any of the values together, from none to all of them

Gruß,

Amica

[Slava]

bei einem feld der "feld set('true') not null" ist, erwarte ich logischeweise nur ein einziger wert und zwar 'true' (so eine spalte kann man ganz auslassen).

"Set" ist für die Anzeige von meheren Zuständen gleichzeitg ausgedacht und ein einzelner Eintrag set('true') sieht schon ein wenig verdächtigt aus

Die Tatsache , dass
" update tabelle set feld= ''; "
eine set-spalte bei MySql tatsächlich mit leerem String verändert, ist zwar machbar, aber leider verwirrend

Die Frage ist auch, ob so ein (meine Meinung nach ein falschen) Verhalten auch in den nächsten Versionen vom Mysql unterstützt wird.

[AmicaNoctis]

*OT-Diskussion abgetrennt*

[onemorenerd]

Völlig falsch! Ich hab im ersten Beitrag dieses Threads schon ziemlich ausführlich erklärt, wie sich das verhält. Ich kann genau so auf int casten und erhalte den richtigen Wert - sowohl beim Select als auch beim Insert.

Ohja stimmt. Ich hatte schon vergessen, dass du kein 'false' im SET hast. Jedenfalls musst du auch casten. Beim Schreiben in die DB mit int(), beim Lesen mit bool(). Genau das muss man auch bei TINYINT.

In deiner selbstgebauten DB-Abstraktion hast du ein bißchen Code, der automatisch richtig castet. Aber dazu muss dieser Code auch das DB-Schema kennen. Sonst könnte man in ein Textfeld "true" eingeben und beim nächsten Aufruf wäre es eine Checkbox.
Woher kennt dein Code das DB-Schema? Offensichtlich liest er es aus der DB. Das kostet.

Ich will doch nicht jedes Mal, wenn sich an der DB ne Kleinigkeit ändert, die kompletten Model-Klassen durchwühlen

Wenn sich bei mir das DB-Schema ändert, spiegelt sich das zuerst im Code wider. Propel, Doctrine, sogar Drupal ...

[AmicaNoctis]

Das kann man am Präfix des Spaltennamens erkennen.

Unzuverlässig.

Ich weiß, du willst es lieber direkt am Wert erkennen.

Nein, am Typ!

aber dafür musst du beim Schreiben in die DB genau auf den Typ achten bzw. konvertieren. Denn aus einem Formular kommt von einer Checkbox irgendwas (vom User manipuliertes). Du musst daraus 'true' oder 'false' machen, während für TINYINT-Spalten ein Cast zu int genügt.

Völlig falsch! Ich hab im ersten Beitrag dieses Threads schon ziemlich ausführlich erklärt, wie sich das verhält. Ich kann genau so auf int casten und erhalte den richtigen Wert - sowohl beim Select als auch beim Insert. Das ist alles völlig logisch und intuitiv.

Eigentlich ist das alles nur eine Geschmacksfrage und imho kaum praxisrelevant. Ich habe jedenfalls schon ewig nichts mehr so programmiert, dass die Applikation den Datentyp aus dem DB-Schema oder -Werten erkennen muss.

Es ist praxisrelevant. Ich will doch nicht jedes Mal, wenn sich an der DB ne Kleinigkeit ändert, die kompletten Model-Klassen durchwühlen, um die Änderungen dort auch vorzunehmen. Außerdem habe ich eine generische ReST-Schnittstelle zu MySQL entwickelt, die gar nicht realisierbar wäre, wenn ich nicht die strukturellen Metadaten der Datenbank auslesen würde. Das alles ist unter dem Namen DRY-Prinzip bekannt und durchaus sinnvoll, wenn man nicht für jedes Projekt alles doppelt modellieren will (DB und Model-Klassen).

[onemorenerd]

Das weiß ich doch, mir geht es aber darum, dass ich bei einer tinyint-Spalte nicht programmatisch feststellen kann, ob es eine Ziffer als solche repräsentieren soll oder einen Wahrheitswert ...

Das kann man am Präfix des Spaltennamens erkennen. Ich weiß, du willst es lieber direkt am Wert erkennen. Das klappt zwar mit deiner SET-Variante, aber dafür musst du beim Schreiben in die DB genau auf den Typ achten bzw. konvertieren. Denn aus einem Formular kommt von einer Checkbox irgendwas (vom User manipuliertes). Du musst daraus 'true' oder 'false' machen, während für TINYINT-Spalten ein Cast zu int genügt.

Eigentlich ist das alles nur eine Geschmacksfrage und imho kaum praxisrelevant. Ich habe jedenfalls schon ewig nichts mehr so programmiert, dass die Applikation den Datentyp aus dem DB-Schema oder -Werten erkennen muss.

[AmicaNoctis]

Die Werte 2-9 sind in PHP auch true.

Das weiß ich doch, mir geht es aber darum, dass ich bei einer tinyint-Spalte nicht programmatisch feststellen kann, ob es eine Ziffer als solche repräsentieren soll oder einen Wahrheitswert, genauer gesagt: Soll ich das Feld dann als Checkbox realisieren oder als Textfeld (evtl. mit Tasteninterzeptor, der nur Zifferntasten akzeptiert)?

[onemorenerd]

Eben, daher halte ich das für absolut ungeeignet.

Die Werte 2-9 sind in PHP auch true.

[AmicaNoctis]

tinyint(1) kann leider auch die werte von 2 bis 9 erhalten

Eben, daher halte ich das für absolut ungeeignet.

bei "enum('0','1') not null" hast du wirklich nur 2 Zustände

Der Nachteil an enum ist aber, dass die Werte in einem numerischen Kontext als 1 für false und 2 für true zurückgegeben werden und man beim Einfügen ganz genau drauf achten muss, ob sie als Strings oder als Zahl übergeben werden, da 1 false wäre, aber '1' true. Daher finde ich set('true') not null ideal, weil false dort als 0 und true als 1 rauskommt.

[Slava]

wir verwenden enum('0','1') not null default '0'.

tinyint(1) kann leider auch die werte von 2 bis 9 erhalten, bei "enum('0','1') not null" hast du wirklich nur 2 Zustände

[schmalle]

Feldname beginnt mit B_ und ist Tinyint(1) unsigned not null. Set kommt bei mir nur in Frage, wenn ich Felder mit mehreren Werten gleichzeitig brauche, nach denen ich schnell suchen muss.

[Quetschi]

Ich habe dem Gedanken pro Boolean ein ganzes Feld zu verschwenden abgeschworen, sofern ich mehr als ein Boolschen Wert in einer DB speichern möchte. Ist das der Fall greife ich zu SET und nenne dieses Feld einfach "Booleans".

Booleans SET('Klima', 'Servo', 'Xenon', 'Lenkrad')

Ist also sozusagen eine minimal abgewandelte Variante von 'set('true') not null' wo der Name des DB-Feldes ansich die Namensgebung übernimmt.

Hab sowas vor einer Zeit mal gegen die andere Methode mit tinyint(1) unsigned not null getestet. Bei vielen Booleans blieb die SET-Methode beim Speicherplatzverbrauch im Vorteil, jedoch war interessant, das MySql viele tinyint(1) unsigned not null Felder "intelligent" handled. So war der Speicherplatzverbrauch bei einem Feld bei 7Bytes pro DS und blieb auch bei 4 solchen Feldern bei 7Bytes pro DS.

Bei 10 Feldern gerät die SET-Methode aber schon in Vorteil beim Speicherplatzverbrauch und SELECTs auf größere Datenmengen waren auch schneller.

[unset]

Früher hab ich Enums verwendet, mitlerweile dann doch nur tinyints. Das meisste wird aber halt auch schon in den Modellen abgefackelt.

[AmicaNoctis]

Ich benutze BOOLEAN, was ja nur ein Alias für TINYINT(1) ist. Und ich gebe den Spalten ein Präfix "is", also zum Beispiel isEnabled.

So hatte ich es erst auch gemacht, aber das war mir für DRY-Anwendungen zu unsicher. Außerdem komme ich mit is_ nicht in allen Fällen hin. Ich brauche dann noch has_ und can_, weil mir solche Konstrukte wie is_having_ oder is_able_to_have_ irgendwann auch zu albern wurden

[onemorenerd]

Ich benutze BOOLEAN, was ja nur ein Alias für TINYINT(1) ist. Und ich gebe den Spalten ein Präfix "is", also zum Beispiel isEnabled.