Memorizzazione del sesso (genere) nel database

Voglio archiviare il genere di un utente in un database con il minor costo (dimensioni / prestazioni) possibile.

Finora, mi vengono in mente 3 scenari

1. Int - allineato con Enum nel codice (1 = Maschio, 2 = Femmina, 3 = ...)
2. char (1) - Memorizza m , f o un altro identificatore a carattere singolo
3. Bit (booleano) : esiste un nome campo appropriato per questa opzione?

Il motivo per cui chiedo è a causa di questa risposta che menziona che i caratteri sono più piccoli dei booleani .

Vorrei chiarire che sto utilizzando MS SQL 2008, che FUNZIONA , infatti, hanno il tipo di dati bit.

Definirei la colonna "genere".

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

Il tipo di dati BIT può essere escluso perché supporta solo due sessi possibili che è inadeguato. Sebbene INT supporti più di due opzioni, sono necessari 4 byte: le prestazioni saranno migliori con un tipo di dati più piccolo / più stretto.

CHAR(1)ha il vantaggio su TinyINT : entrambi accettano lo stesso numero di byte, ma CHAR fornisce un numero più stretto di valori. L'utilizzo CHAR(1)renderebbe l'uso di "m", "f", ecc. Chiavi naturali, rispetto all'uso di dati numerici che sono chiamati chiavi surrogate / artificiali. CHAR(1)è supportato anche su qualsiasi database, qualora fosse necessario eseguire il porting.

Conclusione

Vorrei usare l'opzione 2: CHAR (1).

appendice

Un indice sulla colonna del genere probabilmente non sarebbe utile perché non esiste alcun valore in un indice su una colonna con cardinalità bassa. Significato, non c'è abbastanza varietà nei valori per l'indice per fornire alcun valore.

Esiste già uno standard ISO per questo; non c'è bisogno di inventare il tuo schema:

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

Secondo lo standard, la colonna dovrebbe essere chiamata "Sesso" e il tipo di dati "più vicino" sarebbe minuscolo con un vincolo CHECK o una tabella di ricerca, a seconda dei casi.

In medicina ci sono quattro generi: maschio, femmina, indeterminato e sconosciuto. Potresti non aver bisogno di tutti e quattro ma sicuramente hai bisogno di 1, 2 e 4. Non è appropriato avere un valore predefinito per questo tipo di dati. Ancor meno per trattarlo come un booleano con stati 'is' e 'non'.

Un Int(o TinyInt) allineato a unEnum campo sarebbe la mia metodologia.

Innanzitutto, se hai un singolo bitcampo in un database, la riga utilizzerà comunque un byte intero, quindi per quanto riguarda il risparmio di spazio, ripaga solo se hai piùbit campi.

In secondo luogo, le stringhe / i caratteri hanno un "valore magico", indipendentemente da quanto possano sembrare evidenti in fase di progettazione. Per non parlare, consente alle persone di archiviare qualsiasi valore che non necessariamente mapperebbero a qualcosa di ovvio.

Terzo, un valore numerico è molto più semplice (e pratica migliore) per cui creare una tabella di ricerca, al fine di imporre l'integrità referenziale e può correlare 1-a-1 con un enum, quindi c'è parità nella memorizzazione del valore in memoria all'interno l'applicazione o nel database.

Uso char 'f', 'm' e 'u' perché suppongo il genere da nome, voce e conversazione, e talvolta non conosco il genere. La determinazione finale è la loro opinione.

Dipende davvero da quanto conosci la persona e se i tuoi criteri sono la forma fisica o l'identità personale. Uno psicologo potrebbe aver bisogno di opzioni aggiuntive: incrocio a femmina, incrocio a maschio, trans a femmina, trans a maschio, ermafrodita e indeciso. Con 9 opzioni, non chiaramente definite da un singolo personaggio, potrei seguire il consiglio di Hugo di un piccolo numero intero.

L'opzione 3 è la soluzione migliore, ma non tutti i motori DB hanno un tipo "bit". Se non ne hai un po ', allora TinyINT sarebbe la soluzione migliore.

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;

inserisci qui la descrizione del link

Vorrei andare con l'opzione 3 ma più colonne di bit NON NULLABLE anziché una. IsMale (1 = Sì / 0 = No) IsFemale (1 = Sì / 0 = No)

se richiesto: IsUnknownGender (1 = Sì / 0 = No) e così via ...

Ciò consente una facile lettura delle definizioni, una facile estensibilità, una facile programmabilità, nessuna possibilità di utilizzare valori esterni al dominio e nessun requisito di una seconda tabella di ricerca + vincoli FK o CHECK per bloccare i valori.

EDIT: correzione, è necessario almeno un vincolo per assicurarsi che i flag impostati siano validi.