[spip-dev] Valeurs booléennes dans les tables MySQL

Y a t-il une raison pour que des tables comme spip_meta ou bien
spip_groupes_mots utilisent des valeurs oui/non plutôt que les
booléens de SQL ?

MySQL n'a pas de booléens ?

Y a t-il une raison pour que des tables comme spip_meta ou bien
spip_groupes_mots utilisent des valeurs oui/non plutôt que les
booléens de SQL ?

Même pour les statuts, on passe des chaînes de caractères alors qu'on
devrait avoir des énumérations (je crois). Mais la base de données, c'est
pas ma spécialité...

-- Fil

Il me semble que c'est php 3 qui ne gère pas les booléens en natif (pas de
type boolean), d'où l'obligation (pas très lourde) de passer par des valeurs
oui/non. Pour MySQL, il gère les booléens, mais faudrait convertir les
données...

Si je me gourre, merci de me le dire (je suis pas spécialiste non plus) :wink:

Claude
cthomassin@wanadoo.fr

Stephane Bortzmeyer wrote:
"Y a t-il une raison pour que des tables comme spip_meta ou bien
spip_groupes_mots utilisent des valeurs oui/non plutôt que les
booléens de SQL ?"

Pour spip_meta : oui car les valeurs ne sont pas toutes booléennes,
donc on a pris un type plutôt large (varchar).

Pour spip_groupes_mots, et autres : non, c'est juste du design
paresseux (comme pour les statuts qui auraient pu être des enums).
Note que ça permet quand même d'ajouter d'autres valeurs possibles
sans faire de alter table derrière.

Je ne sais plus si MySQL a des booléens mais on peut les émuler
avec un enum à deux valeurs.

a+

Antoine.

@ Antoine Pitrou <antoine@rezo.net> :

Pour spip_groupes_mots, et autres : non, c'est juste du design
paresseux (comme pour les statuts qui auraient pu être des enums).
Note que ça permet quand même d'ajouter d'autres valeurs possibles
sans faire de alter table derrière.

Au début (je ne connaissais pas les ENUM) je m'étais demandé pourquoi on
n'avait pas mis des chiffres 0,1,2,3... mais le code est plus lisible avec
des statuts 'publie', 'prop' etc.

Si ça optimise de passer en ENUM, y'a qu'à !

-- Fil

Fil wrote:

Au début (je ne connaissais pas les ENUM) je m'étais demandé pourquoi on
n'avait pas mis des chiffres 0,1,2,3... mais le code est plus lisible avec
des statuts 'publie', 'prop' etc.

Si ça optimise de passer en ENUM, y'a qu'à !

Ca ne change pratiquement rien, à vue de nez.