Te recomendamos que pruebes esta resolución en un ambiente controlado antes de pasarlo a producción, saludos.
Solución:
Ya existe una norma ISO para esto; no es necesario que inventes tu 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 una tabla de búsqueda, según corresponda.
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 la misma cantidad de bytes, pero CHAR proporciona una cantidad de valores más estrecha. Usando CHAR(1) haría que usar “m”, “f”, etc. sea natural keysfrente al uso de datos numéricos que se denominan sustitutos/artificiales keys. CHAR(1) también es compatible con cualquier base de datos, en caso de que sea necesario portar.
Conclusión
Yo usaría la Opción 2: CHAR(1).
Apéndice
Un índice en la columna de género probablemente no ayuda porque no hay valor en un índice en una columna de cardinalidad baja. Es decir, no hay suficiente variedad en los valores para que el índice proporcione algún valor.
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. Menos aún para tratarlo como un booleano con estados ‘es’ y ‘no es’.