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

[onemorenerd]

"store any of the values together, from none to all of them" beißt sich mit "feld set('true') not null".
Entspricht das Verhalten von MySQL in dieser Sache eigentlich dem Standard? Handhaben es andere DBMS genauso?

[AmicaNoctis]

Null hat doch damit gar nichts zu tun. Null bedeutet: nicht definierter oder fehlender Wert. Die leere Menge (genau so wie der leere String bei varchar oder die 0 bei int) sind dagegen sehr wohl definierte Werte.

Andere DBMS haben nicht zwangsläufig einen ENUM- oder SET-Typ, da beide nicht zum ANSI SQL 92 Standard gehören. Wenn aber ein SET-Typ vorhanden ist, sollte er genau so funktionieren wie in MySQL, denn alles andere wäre unlogisch. Eine Menge ist nun mal eine Menge und sollte sich auch wie das gleichnamige mathematische Konzept verhalten.

[onemorenerd]

0 ist ein int, ein leerer String ist ein String und eine leere Menge ist eine Menge. Damit bin ich völlig einverstanden.
Wenn ich einer Spalte vom Typ set('true') die Einermenge {'true'} zuweise, bekomme ich den String "true" zurück.
Wenn ich der Spalte die leere Menge {} zuweise, bekomme ich einen leeren String zurück.
Das ist imho nicht sehr intuitiv, zumal der leere String laut Spaltendefinition kein zugelassenes Element ist.
Die leere Menge wird durch einen leeren String ausgedrückt.
Anders gehts ja auch nicht. Sie mit NULL auszudrücken widerspräche der dreiwertigen Logik.

Es mag also alles funktionieren, aber intuitiv ist das wirklich nicht und es würde mich auch nicht wundern, wenns gar nicht dem Standard entspricht.

[AmicaNoctis]

zumal der leere String laut Spaltendefinition kein zugelassenes Element ist.

Der leere String ist nichtmal ein zulässiges Element für eine Spaltendefinition, weil er ja als Repräsentant der leeren Menge verwendet wird

Du kannst keine set('abc', 'de', 'f', '')-Spalte definieren.

[onemorenerd]

Edit: set('a','') ist sehr wohl zulässig. Habs grad getestet. Und wenn man einem Datensatz in dieser Spalte '' zuweist, bekommt man das gleiche zurück wie bei der leeren Menge, d.h. man kann es gar nicht unterscheiden. Ziemlich krank!

[onemorenerd]

Angenommen eine Spalte hat den Typ set('a','b') und ein Datensatz enthält in dieser Spalte die Menge {'a', 'b'}. In PHP bekommt man dann den String "a,b" zurück. Um daraus sowas wie eine Menge zu machen, greift man meist zu explode(',' ...). Alles schick, man erhält ein Array mit zwei Elementen.

Aber hat ein Datensatz nun die leere Menge in dieser Spalte, würde man ein leeres Array erwarten. Doch explode() liefert ein Array mit einem Element, dem leeren String. Imho funktioniert explode() in dieser Hinsicht korrekt.

[AmicaNoctis]

Edit: set('a','') ist sehr wohl zulässig. Habs grad getestet. Und wenn man einem Datensatz in dieser Spalte '' zuweist, bekommt man das gleiche zurück wie bei der leeren Menge, d.h. man kann es gar nicht unterscheiden. Ziemlich krank!

Kann ich bestätigen. Finde ich auch krank. Ich war mir sicher, dass das nicht zulässig ist.

Was den Vergleich mit explode betrifft: Es würde genauso korrekt arbeiten, wenn es ein leeres Array zurückgeben würde, nur bist du es gewohnt, ein Array mit einem leeren String zu bekommen, so dass du es inzwischen logisch findest. Ein PHP-Anfänger könnte das wieder ganz anders sehen. Für solche Spezialfälle gibt es kein korrekt oder nicht, nur spezifikationskonformes Verhalten oder nicht. Wenn das alles mit Logik entscheidbar wäre, bräuchte man ja keine Doku

PS: Guck dir mal die Spezialfälle für empty() an und sag mir dann mal, ob du das logisch findest oder dich nur dran gewöhnt hast.

[onemorenerd]

Ja sicher gibt es viele Eigenheiten/Spezialitäten in PHP. Aber explode() gehört nicht dazu. Es ist keine Entscheidung der Enwickler von PHP gewesen, dass sich explode() so verhält. Es muss sich so verhalten, denn würde es hierbei

$emptyString = '';
var_dump(explode(',', $emptyString)); 

ein leeres Array zurückgeben, dann müsste es das hierfür auch

$emptyString = '';
var_dump(explode(',', $emptyString.','.$emptyString)); 

und das ginge ja absolut nicht. Dafür müsste man ja in PHP leere Strings verbieten - unmöglich in einer ernst zu nehmenden Sprache.

... muss man sich mal vorstellen, jedes Formularfeld ein Pflichtfeld

[Quetschi]

Jau - beknackt ist dagegen, dass explode immer noch ein Array, mit einem Element das einen leeren String enthält, zurückgibt, wenn du $emptyString = NULL machst.

[onemorenerd]

Auch das ist nichts besonderes bzw. es liegt nicht an explode. Die Funktion erwartet als zweiten Parameter einen String. Wenn du $emptyString mit NULL belegst, castet PHP das zum String, bevor es die Funktion aufruft. Dass NULL zu einem leeren String gecastet wird, kann man vielleicht als beknackt empfinden - das ist tatsächlich so eine Eigenheit von PHP. Die Entwickler hätten es auch so machen können, dass NULL zu "0" (String mit Zeichen 0) wird oder zu "NULL". Beides wäre aber noch beknackter.

[Quetschi]

Genau das sollte IMHO halt nicht geschehen - wenn explode einen Parameter bekommt, der keinen akzetablen Datentyp enthält, sollte es meinetwegen ein false liefern, aber nicht etwas, was letztenendes doppel- bzw. gar mehrdeutig ist, weil der zurückgelieferte Wert auch einen anderen Ursprung haben könnte.

So errinnert das einen entfernt an die Heisenbergsche Unschärferelation...

[onemorenerd]

Wie ich bereits sagte, das ist keine Macke von explode(). Das ist bei allen Funktionen so und es sind nicht die Funktionen, die sich ihre Parameter zurecht-casten. Das macht die Engine.
Im Manual heißt es "a variable's type is determined by the context in which the variable is used" oder "The type of a variable is not usually set by the programmer; rather, it is decided at runtime by PHP depending on the context in which that variable is used."

Wenn man explode() irgendwas vorwerfen kann, dann dass es keinen dritten Parameter bool $strict hat und bei $strict == true das Type Juggling verhindert.

[Quetschi]

Wenn man explode() irgendwas vorwerfen kann, dann dass es keinen dritten Parameter bool $strict hat und bei $strict == true das Type Juggling verhindert.

Wäre eigentlich nicht schlecht, wenn man das Global festlegen könnte. Manchmal ist es ja nett, aber manchmal zwingt es einem halt auch wieder zu gewissen Umwegen.

[unset]

Wenn man explode() irgendwas vorwerfen kann, dann dass es keinen dritten Parameter bool $strict hat und bei $strict == true das Type Juggling verhindert.

Und bevor man dann anfängt zu lamentieren, wie sich explode nun verhalten sollte und dass ja eh alles total doof ist, kann man sich auch einfach mal die Zeit nehmen, und das selbst comitten

Das bezieht sich jetzt nicht auf dich sondern auf die generelle "PHP machts anders als es eigentlich richtig wäre, und deswegen ist alles scheiße"-Mentalität, die in letzter Zeit hier Einzug hält