naming-conventions - name - naming convention examples

¿Es el nombre IsFemale inadecuado para una columna de base de datos? (12)

Simplemente navegando por nuestro esquema de db y encontré un campo llamado ''IsFemale''

¿Es bueno el nombre, o es algo risible?

¿Qué hay de malo con el "sexo" clásico y los subtipos compatibles, como M, F, etc ...

¿Solo vas a tener que verificar si "IsFemale" es verdadero / falso?

¿No sería más apropiada una columna como "PersonType" o algo así? De esa manera, podría tener "mujer", "hombre", "compañía" y demás, más valores posibles.

Bagazo

PD: pero si elige usar una columna "bit" (booleano), entonces el prefijo "Es" o "Tiene" es una buena opción, en mi opinión, ¡deja bastante claro que es un booleano!

Bueno, lo típico es tener una columna de "sexo", pero puede terminar con clientes desorientados que intentan archivarla con valores como "dos veces por semana".

Otro problema es que depende del lenguaje. Por ejemplo, en inglés M significará M an, mientras que en español puede significar M ujer (mujer).

Cada base de datos con la que he trabajado ha usado un nombre de columna de Género con valores 0 para Mujer y 1 para Hombre. Siempre he asumido que estos valores se asignaron de la misma manera que los equipos electrónicos tienen conectores que se describen como femeninos o masculinos.

Si IsFemale es risible o no depende de la intención del sistema, sin embargo, parece haber pintado la aplicación en una esquina. Los campos de género, por ejemplo, pueden crecer para adaptarse a un "tipo" adicional, pero IsFemale obviamente solo será verdadero o falso y, por lo tanto, no será extensible en absoluto.

Debes seguir con la norma ISO si es posible.

ISO / IEC 5218 Tecnología de la información: los códigos para la representación de los sexos humanos es un estándar internacional que define una representación de los sexos humanos a través de un código de un solo dígito que no tiene en cuenta el idioma. ...
Los cuatro códigos especificados en ISO / IEC 5218 son:
0 = no conocido,
1 = hombre,
2 = femenino,
9 = no aplicable.
El estándar especifica que su uso puede ser referido por el designador "SEXO".

Está claro que el interrogador está preocupado (con razón) por el hecho de que el diseñador de la base de datos no haya tenido en cuenta un lenguaje de valor neutral.

(Tenga en cuenta que lo políticamente correcto es (con razón) ya no se considera aceptado como lenguaje de valor neutral).

Como diseñador de computadoras, usted tiene la obligación particular de asegurarse de que sus diseños no incluyan o propaguen, sin darse cuenta, la preferencia de género o la superioridad.

Si bien el diseñador puede haber presumido ingenuamente que IsFemale le daría a las mujeres un 1 y, por lo tanto, un valor más alto / superior, los valores reales a menudo reciben el valor de -1. Sin mencionar las culturas donde 0 es un valor sagrado.

En la entrega de la próxima semana, cubriremos a las personas que son teoría intersex y queer y sus implicaciones para los estándares de denominación de variables.

Las mujeres y los hombres no se excluyen mutuamente, por lo que tendrás que encontrar algo para transexuales, unisex, etc.

Para hacer esto lo más empresarial posible, cree una columna GenderTypeID :

GenderTypes ----------- GenderTypeID Name Greeting 1 Male Dear Sir 2 Female Dear Madam 3 Unisex Dear Sir and Madam 4 Unknown Dear Sir or Madam 5 Android Dear Artificial Life Form

... y así.

Para sistemas simples donde no hay ambigüedad sexual, uso IsMale. La alternativa sería utilizar una tabla de búsqueda si sus requisitos incluyen individuos intersexuales. Si solo tiene hombres y mujeres, usar algo que no sea un valor booleano introduce complejidad y ambigüedad innecesarias en el sistema.

Si estás preguntando si es risible, eso depende. ¿Sería mejor Male, chovinista? (¡Es una broma!)

Mi conjetura es que quien diseñó la base de datos pensó en reglas comerciales especiales para mujeres y las diseñó de esta manera.

Realmente no hay una razón por la que los hombres deban ser verdaderos y las mujeres deben ser falsos, y es posible que su base de datos sea menos eficiente en el uso de una comparación de caracteres y caracteres.

Desde el punto de vista de la programación, evitar los booleanos en las tablas tiene sentido por las mismas razones que tiene sentido evitar los booleanos en los parámetros de función.

Tal vez nombrar la columna "género" (char con ''M'', ''F'') sería más "sensible".

isFemale indica un problema mayor con su esquema, algo como eso debería generalizarse, o posiblemente incluso normalizarse:

Como tener una columna de sexo en tu mesa, que es un FK a una mesa de sexo:

--------------------- | ID | Type | |-------------------| | 1 | Male | | 2 | Female | | 3 | Yes Please | ---------------------

Tenga en cuenta que, en realidad, no haga esto, es una tontería, a menos que planee admitir géneros inusuales. Todavía creo que una columna genérica es mejor que un bit isFemale.

Gender parece ser una mejor opción, pero si desea o necesita utilizar una columna booleana, solo hay dos opciones: IsMale o IsFemale.