Bonjour,

je possède une variable qui a pour valeur soit false ou true.

Je souhaite que lorsque que j'enregistre cette valeur dans un champ sql, false soit un champ NULL (et pas vide !).

Comment je peux faire ?

Actuellement dès que la valeur est égale à false et que je l'enregistre dans ma bdd, le champ est vide mais pas NULL comme je le souhaite.

Par ailleurs quelle est la différence de poids d'un champ sql qui est égal à vide ou NULL ?

Merci d'avance pour votre aide

-
Edité par sagaff 17 novembre 2018 à 12:22:19

Bah tu fais un test sur ta variable et tu bindes NULL si elle vaut FALSE, je ne vois pas le problème ...

FALSE casté en string donne chaîne vide donc le résultat observé est parfaitement normal.

> Par ailleurs quelle est la différence de poids d'un champ sql qui est égal à vide ou NULL ?

Tu as cherché/lu la doc ?

• sur un CHAR(10) * : 10 octets vu que c'est rempli avec des espaces
• sur un VARCHAR(10) * : 1 octet pour la taille + 0 pour la chaîne vide
• NULL : 1 bit (1 octet pour 8 colonnes) mais ça dépend des "options" et du moteur de stockage

* 10 pris en exemple, mais pour une taille max de X et pour X < 255, substituer 10 par X, c'est pareil

-
Edité par julp 17 novembre 2018 à 12:47:31

Comme dit julp, ta colonne doit accepter le null (il suffit pour cela de ne pas déclarer NOT NULL lors de sa création). Si tu veux qu'elle ne prenne qu'un bit, et que sa valur se comporte comme un booléen, tu la mets de type varchar(0) et tu entres soit une chaîne vide, soit null dans ta requête d'insertion.

Cordialement.

> Si je fais plutot une valeur 0 ou 1

Ou BOOL (alias TINYINT(1)), non ? Pas besoin de se compliquer la vie avec autre chose qu'un booléen pour deux valeurs type oui/non, vrai/faux !

-
Edité par julp 17 novembre 2018 à 21:47:12

« Si je fais plutot une valeur 0 ou 1 »

l'enum sur deux valeurs fonctionne très bien, mais prend un octet (comme un tinyint ou un bool) plutôt que 1 bit.

Enum est plus sécuritaire puisque tu ne peux pas insérer d'autres valeurs que celles déclarées à la création. Alors que tu peux mettre 89 par exemple dans un (faux) booléen !

> Enum est plus sécuritaire puisque tu ne peux pas insérer d'autres valeurs que celles déclarées à la création. Alors que tu peux mettre 89 par exemple dans un (faux) booléen !

Mouais, bien que ce ne soit pas nécessairement un exemple, MySQL fonctionne comme PHP : toute valeur non nulle est une valeur vraie. Après : les contraintes CHECK ne sont pas implémentées si vraiment on voulait se restreindre aux valeurs 0/1 (sinon il faut passer par un trigger qui lève une erreur), encore qu'on n'en serait pas à aller dans cette voie si MySQL disposait d'un vrai type booléen. Bref, même si tu avais 89 comme valeur, si derrière au niveau de tes requêtes la colonne est utilisée comme un booléen, ça ne posera pas de problème (ie WHERE col - vrai pour 89 - et non WHERE col = 1 - faux pour 89 évidemment)

Et ENUM, je me méfierais tout de même :

1. il est possible d'indiquer la valeur d'un enum par la valeur elle-même comme son index
2. MySQL tente de convertir une valeur qui n'existe pas en index

(cf doc)

Et dans le cas particulier où '0' et '1' seraient les valeurs de ladite ENUM, considérant ces deux points, on risque quelques surprises et confusions avec 0/1 en tant que littéral numérique.

-
Edité par julp 18 novembre 2018 à 12:01:15