Almacenar sexo (género) en la base de datos

Quiero almacenar el género de un usuario en una base de datos con el menor costo (tamaño / rendimiento) posible.

Hasta ahora, me vienen a la mente 3 escenarios

1. Int - alineado con Enum en el código (1 = Masculino, 2 = Femenino, 3 = ...)
2. char (1) : almacena m , f u otro identificador de un solo carácter
3. Bit (booleano) : ¿hay un nombre de campo apropiado para esta opción?

La razón por la que pregunto es por esta respuesta que menciona que los caracteres son más pequeños que los booleanos .

Debo aclarar que estoy usando MS SQL 2008, que TIENE , de hecho, tienen el tipo de datos bit.

Llamaría a la columna "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

El tipo de datos BIT se puede descartar porque solo admite dos géneros posibles, lo cual es inadecuado. Si bien INT admite más de dos opciones, requiere 4 bytes: el rendimiento será mejor con un tipo de datos más pequeño / más estrecho.

CHAR(1)tiene la ventaja sobre TinyINT : ambos toman el mismo número de bytes, pero CHAR proporciona un número más estrecho de valores. El uso CHAR(1)haría que usar "m", "f", etc., las teclas naturales, en comparación con el uso de datos numéricos que se denominan claves sustitutas / artificiales. CHAR(1)también es compatible con cualquier base de datos, en caso de que sea necesario portar.

Conclusión

Usaría la Opción 2: CHAR (1).

Apéndice

Un índice en la columna de género probablemente no ayudaría porque no hay valor en un índice en una columna de baja cardinalidad. Es decir, no hay suficiente variedad en los valores para que el índice proporcione ningún valor.

Ya existe un estándar ISO para esto; No es necesario inventar su propio esquema:

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

Según el estándar, la columna debe llamarse "Sexo" y el tipo de datos 'más cercano' sería tinyint con una restricción CHECK o tabla de búsqueda según corresponda.

En medicina hay cuatro géneros: masculino, femenino, indeterminado y desconocido. Es posible que no necesite los cuatro, pero ciertamente necesita 1, 2 y 4. No es apropiado tener un valor predeterminado para este tipo de datos. Incluso menos para tratarlo como un booleano con estados 'es' y 'no es'.

Un Int(o TinyInt) alineado a unEnum campo sería mi metodología.

Primero, si tiene un solo bitcampo en una base de datos, la fila seguirá utilizando un byte completo, por lo que, en lo que respecta al ahorro de espacio, solo vale la pena si tiene múltiplesbit campos.

En segundo lugar, las cadenas / caracteres tienen una sensación de "valor mágico", independientemente de lo obvio que puedan parecer en el momento del diseño. Sin mencionar que permite a las personas almacenar casi cualquier valor que no necesariamente asignarían a algo obvio.

Tercero, un valor numérico es mucho más fácil (y una mejor práctica) para crear una tabla de búsqueda, con el fin de hacer cumplir la integridad referencial, y puede correlacionar 1 a 1 con una enumeración, por lo que hay paridad en el almacenamiento del valor en la memoria dentro de la aplicación o en la base de datos.

Uso char 'f', 'm' y 'u' porque supongo el género por nombre, voz y conversación, y a veces no sé el género. La determinación final es su opinión.

Realmente depende de qué tan bien conozca a la persona y si su criterio es la forma física o la identidad personal. Un psicólogo podría necesitar opciones adicionales: cruzado a femenino, cruzado a masculino, trans a femenino, trans a masculino, hermafrodita e indeciso. Con 9 opciones, no claramente definidas por un solo personaje, podría seguir el consejo de Hugo de pequeño número entero.

La opción 3 es su mejor opción, pero no todos los motores DB tienen un tipo "bit". Si no tiene un poco, entonces TinyINT sería su mejor apuesta.

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;

ingrese la descripción del enlace aquí

Iría con la Opción 3 pero múltiples columnas de bits NO NULABLES en lugar de una. IsMale (1 = Sí / 0 = No) IsFemale (1 = Sí / 0 = No)

si se requiere: IsUnknownGender (1 = Sí / 0 = No) y así sucesivamente ...

Esto facilita la lectura de las definiciones, la extensibilidad fácil, la facilidad de programación, la posibilidad de usar valores fuera del dominio y el requisito de una segunda tabla de búsqueda + restricciones FK o CHECK para bloquear los valores.

EDITAR: Corrección, necesita al menos una restricción para garantizar que los indicadores establecidos sean válidos.