Stockage du sexe (genre) dans la base de données

Je souhaite stocker le sexe d'un utilisateur dans une base de données avec un coût (taille / performances) aussi faible que possible.

Jusqu'à présent, 3 scénarios me viennent à l'esprit

1. Int - aligné sur Enum dans le code (1 = Male, 2 = Female, 3 = ...)
2. char (1) - Stocke m , f ou un autre identificateur de caractère unique
3. Bit (booléen) - y a-t-il un nom de champ approprié pour cette option?

La raison pour laquelle je pose la question est à cause de cette réponse qui mentionne que les caractères sont plus petits que les booléens .

Je dois préciser que j'utilise MS SQL 2008, qui FONCTIONNE ont en fait le type de données bit.

J'appellerais la colonne «sexe».

Data Type   Bytes Taken          Number/Range of Values
------------------------------------------------
TinyINT     1                    255 (zero to 255)
INT         4            -       2,147,483,648 to 2,147,483,647
BIT         1 (2 if 9+ columns)  2 (0 and 1)
CHAR(1)     1                    26 if case insensitive, 52 otherwise

Le type de données BIT peut être exclu car il ne prend en charge que deux genres possibles, ce qui est inadéquat. Alors qu'INT prend en charge plus de deux options, il prend 4 octets - les performances seront meilleures avec un type de données plus petit / plus étroit.

CHAR(1)a l'avantage sur TinyINT - les deux prennent le même nombre d'octets, mais CHAR fournit un nombre plus restreint de valeurs. Utiliser CHAR(1)ferait utiliser des clés naturelles "m", "f", etc., par rapport à l'utilisation de données numériques qui sont appelées clés de substitution / artificielles. CHAR(1)est également pris en charge sur n'importe quelle base de données, en cas de besoin de port.

Conclusion

J'utiliserais l'option 2: CHAR (1).

Addenda

Un index sur la colonne de genre n'aiderait probablement pas, car il n'y a aucune valeur dans un index sur une colonne de cardinalité faible. Cela signifie qu'il n'y a pas assez de variété dans les valeurs pour que l'index fournisse une valeur.

Il existe déjà une norme ISO pour cela; pas besoin d'inventer votre propre schéma:

http://en.wikipedia.org/wiki/ISO_5218

Selon la norme, la colonne doit être appelée "Sex" et le type de données "le plus proche" serait tinyint avec une contrainte CHECK ou une table de recherche selon le cas.

En médecine, il existe quatre genres: masculin, féminin, indéterminé et inconnu. Vous n'avez peut-être pas besoin des quatre, mais vous aurez certainement besoin de 1, 2 et 4. Il n'est pas approprié d'avoir une valeur par défaut pour ce type de données. Encore moins pour le traiter comme un booléen avec des états «est» et «n'est pas».

Un Int(ou TinyInt) aligné sur un Enumchamp serait ma méthodologie.

Premièrement, si vous avez un seul bitchamp dans une base de données, la ligne utilisera toujours un octet complet, donc en ce qui concerne les économies d'espace, cela ne paie que si vous avez plusieurs bitchamps.

Deuxièmement, les chaînes / caractères ont pour eux une sensation de «valeur magique», quelle que soit leur évidence au moment de la conception. Sans oublier, cela permet aux gens de stocker à peu près n'importe quelle valeur qu'ils ne mapperaient pas nécessairement à quelque chose d'évident.

Troisièmement, une valeur numérique est beaucoup plus facile (et meilleure pratique) pour créer une table de recherche, afin de renforcer l'intégrité référentielle, et peut corréler 1 à 1 avec une énumération, il y a donc parité dans le stockage de la valeur en mémoire dans l'application ou dans la base de données.

J'utilise char «f», «m» et «u» parce que je suppose le sexe à partir du nom, de la voix et de la conversation, et parfois je ne connais pas le genre. La décision finale est leur opinion.

Cela dépend vraiment de la façon dont vous connaissez la personne et si vos critères sont la forme physique ou l'identité personnelle. Un psychologue pourrait avoir besoin d'options supplémentaires - croisé vers femme, croisé vers homme, trans vers femme, trans vers homme, hermaphrodite et indécis. Avec 9 options, pas clairement définies par un seul caractère, je pourrais suivre les conseils d'Hugo d'un petit entier.

L'option 3 est votre meilleur choix, mais tous les moteurs DB n'ont pas un type "bit". Si vous n'en avez pas, alors TinyINT serait votre meilleur pari.

CREATE TABLE Admission (
    Rno INT PRIMARY KEY AUTO_INCREMENT,
    Name VARCHAR(25) NOT NULL,
    Gender ENUM('M','F'),
    Boolean_Valu boolean,
    Dob Date,
    Fees numeric(7,2) NOT NULL
);




insert into Admission (Name,Gender,Boolean_Valu,Dob,Fees)values('Raj','M',true,'1990-07-12',50000);
insert into Admission (Name,Gender,Boolean_Valu,Dob,Fees)values('Rani','F',false,'1994-05-10',15000);
select * from admission;

entrez la description du lien ici

J'irais avec l'option 3 mais plusieurs colonnes de bits NON NULLABLE au lieu d'une. IsMale (1 = Oui / 0 = Non) IsFemale (1 = Oui / 0 = Non)

si nécessaire: IsUnknownGender (1 = Oui / 0 = Non) et ainsi de suite ...

Cela permet une lecture facile des définitions, une extensibilité facile, une programmabilité facile, aucune possibilité d'utiliser des valeurs en dehors du domaine et aucune exigence d'une deuxième table de recherche + contraintes FK ou CHECK pour verrouiller les valeurs.

EDIT: Correction, vous avez besoin d'au moins une contrainte pour vous assurer que les indicateurs définis sont valides.