Page 1 sur 1

Type Enum ou Byte pour un champ oui/non ou 0/1

Posté : 01 févr. 2006, 22:35
par Romeo
Qu'est ce qu'il vous semnble le mieux adapté pour un champ oui/nom

enum('0','1') mais dans ce cas les valeurs ne sont pas reconnue comme numérique dans les requêtes.

ou

Byte

Posté : 01 févr. 2006, 22:55
par fab
pour ce type de champ perso j'utlise tinyint(1)

Posté : 01 févr. 2006, 22:58
par Cyrano
Ben comme ça, ça fera deux écoles: pour ce genre de champ à mon sens, il y a pas photo: ENUM ou SET, même pas un TINYINT, on a besoin de stocker deux valeurs possibles, pas 255, donc ENUM est plus approprié et ça permet en outre d'utiliser autre chose que 0 et 1, on peut mettre "oui" et "non", ou encore "Accepté"/"Refusé", etc...

Posté : 02 févr. 2006, 12:32
par Romeo
Merci pour vos réponses.

Ce qui me chagrine un peu avec le type enum, c'est que toutes les données sont reconnues comme alpha-numérique et nom comme valeur numérique.

Ca me choque lors d'une requête d'avoir une valeur numérique encadrée par des guillemets.


Autre chose alors puisque l'on y est.
Cette fois ci j'ai un champ qui comprend seulement des valeurs entieres comprise entre 2005 et 2010 (heu... d'ailleur le champ s'appele 'annee')

Quel est le bon choix ?
enum('2005','2006','2007','2008','2009','2010')
ou
smallint

Merci

Posté : 02 févr. 2006, 12:57
par albat
Je suis allergique aux définitions statiques de types (enum ou set),
donc j'utilise des tinyint comme Fab.

Posté : 02 févr. 2006, 13:30
par Cyrano
Pour des champs recevant des années comme valeur, le type SMALLINT serait approprié puisqu'avec le temps, les valeurs sont appelées à évoluer.

En revanche pour un champ devant stocker une valeur booléenne ou des valeurs qui de toutes façon ne changeront pas genre "oui"/"non"/"sans opinion"/"Vous pouvez répeter la question?" , le type ENUM, tout statique qu'il soit est la solution la plus logique: ce sont des données statiques.

Posté : 17 févr. 2006, 07:21
par 131
Ce qui me chagrine un peu avec le type enum, c'est que toutes les données sont reconnues comme alpha-numérique et nom comme valeur numérique.
C'est plus ou moins normal en fait, si on considere que les valeurs possibles d'enums sont enregistrées dans la structure de la table, et que seul l'index de la valeur est stoqué en enregistrement.

Pour le coup des guillemet, ca prete à des erreurs chez moi aussi, mais bon, ca reste la facon la plus light de stocker un boolean, j'aime

Posté : 19 févr. 2006, 23:05
par Hubert Roksor
ca reste la facon la plus light de stocker un boolean, j'aime
Pourtant, un ENUM prend autant de place qu'un TINYINT lorsqu'il s'agit de stocker un booléen, d'ailleurs c'est le type de champs utilisé par MySQL lorsqu'on utilise BOOLEAN comme type de données.

J'en profite pour balancer l'anecdote que tout le monde connait: la seule façon sous MySQL de stocker une valeur binaire sur un seul bit est de déclarer un champs CHAR(0) NULL et d'utiliser '' et NULL comme valeurs. Et encore, seulement s'il y a 7 autres champs NULL, sinon ça prend un octet comme tout le monde ;)

Posté : 21 févr. 2006, 18:49
par Sysadmin
Je confirme ce que Hubert Roksor dit en citant la documentation officielle de MySQL:
BOOL, BOOLEAN
These types are synonyms for TINYINT(1). A value of zero is considered false. Non-zero values are considered true.
In the future, full boolean type handling will be introduced in accordance with standard SQL.
Donc va pour TINYINT(1) ;)

Posté : 21 févr. 2006, 19:55
par fab
bas besoin de confirmer la parole d'Hubert :p