Armazenando sexo (sexo) no banco de dados

Quero armazenar o sexo de um usuário em um banco de dados com o menor custo possível (tamanho / desempenho).

Até agora, três cenários vêm à mente

1. Int - alinhado com Enum no código (1 = Masculino, 2 = Feminino, 3 = ...)
2. char (1) - armazena m , f ou outro identificador de caractere único
3. Bit (booleano) - existe um nome de campo apropriado para esta opção?

A razão pela qual pergunto é por causa dessa resposta, que menciona que caracteres são menores que booleanos .

Devo esclarecer que eu estou usando o MS SQL 2008, que FAZ , de facto, o tipo de dados bit.

Eu chamaria a coluna "gênero".

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

O tipo de dados BIT pode ser descartado porque suporta apenas dois sexos possíveis, o que é inadequado. Enquanto o INT suporta mais de duas opções, são necessários 4 bytes - o desempenho será melhor com um tipo de dados menor / mais estreito.

CHAR(1)tem vantagem sobre o TinyINT - ambos têm o mesmo número de bytes, mas CHAR fornece um número mais restrito de valores. O uso CHAR(1)tornaria o uso de "m", "f" etc. chaves naturais, versus o uso de dados numéricos que são chamados de chaves substitutas / artificiais. CHAR(1)também é suportado em qualquer banco de dados, caso seja necessário portar.

Conclusão

Eu usaria a opção 2: CHAR (1).

Termo aditivo

Um índice na coluna de gênero provavelmente não ajudaria porque não há valor em um índice em uma coluna de baixa cardinalidade. Ou seja, não há variedade suficiente nos valores para o índice fornecer qualquer valor.

Já existe um padrão ISO para isso; não há necessidade de inventar seu próprio esquema:

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

De acordo com o padrão, a coluna deve ser chamada "Sexo" e o tipo de dados 'mais próximo' seria tinyint com uma restrição CHECK ou tabela de pesquisa, conforme apropriado.

Na medicina, existem quatro gêneros: masculino, feminino, indeterminado e desconhecido. Talvez você não precise dos quatro, mas certamente precisa de 1, 2 e 4. Não é apropriado ter um valor padrão para esse tipo de dados. Ainda menos para tratá-lo como um booleano com os estados 'is' e 'is'.

Um Int(ou TinyInt) alinhado a um Enumcampo seria minha metodologia.

Primeiro, se você tiver um único bitcampo em um banco de dados, a linha ainda usará um byte completo; portanto, quanto à economia de espaço, só compensa se você tiver vários bitcampos.

Segundo, strings / caracteres têm um "valor mágico", independentemente de quão óbvios possam parecer no momento do design. Sem mencionar, ele permite que as pessoas armazenem praticamente qualquer valor que não necessariamente mapeariam para algo óbvio.

Terceiro, um valor numérico é muito mais fácil (e melhor prática) para criar uma tabela de pesquisa, a fim de reforçar a integridade referencial e pode correlacionar 1 a 1 com uma enumeração, para que haja paridade no armazenamento do valor na memória dentro o aplicativo ou no banco de dados.

Uso char 'f', 'm' e 'u' porque suponho que o gênero seja do nome, da voz e da conversa e, às vezes, não conheço o gênero. A determinação final é a opinião deles.

Realmente depende de quão bem você conhece a pessoa e se seus critérios são de forma física ou identidade pessoal. Um psicólogo pode precisar de opções adicionais - passagem para mulher, passagem para homem, passagem para mulher, passagem para homem, hermafrodita e indecisa. Com 9 opções, não claramente definidas por um único caractere, posso seguir o conselho de Hugo de número inteiro minúsculo.

A opção 3 é sua melhor aposta, mas nem todos os mecanismos de banco de dados têm um tipo "bit". Se você não tem um pouco, então o TinyINT seria sua melhor aposta.

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;

insira a descrição do link aqui

Eu iria com a opção 3, mas várias colunas de bits NÃO NULÁVEIS, em vez de uma. IsMale (1 = Sim / 0 = Não) IsFemale (1 = Sim / 0 = Não)

se solicitado: IsUnknownGender (1 = Sim / 0 = Não) e assim por diante ...

Isso facilita a leitura das definições, fácil extensibilidade, fácil programação, nenhuma possibilidade de usar valores fora do domínio e nenhum requisito de uma segunda tabela de pesquisa + restrições FK ou CHECK para bloquear os valores.

EDIT: Correção, você precisa de pelo menos uma restrição para garantir que os sinalizadores definidos sejam válidos.