nombres de los campos booleanos positivo o negativo

campos booleanos de una tabla puede nombrarse con lo positivo frente a lo negativo ...nombres de los campos booleanos positivo o negativo

por ejemplo, llamar a un campo:

"ACTIVE" , 1=on/0=off 
or 
"INACTIVE" , 0=on/1=off

Pregunta: ¿Existe una forma adecuada de tomar este tipo de decisión de diseño de mesa, o es arbitraria?

Mi ejemplo específico es una tabla de mensajes con un campo bool (privado/público). Este campo se establecerá usando una casilla de verificación de formulario cuando un usuario ingresa un nuevo mensaje. ¿Hay algún beneficio al nombrar el campo "público" frente a "privado"?

gracias.

Fuente

2009-09-18 cardflopper

Debería crear otra tabla e implementar una relación de clave externa; consulte mi respuesta para obtener más información. –

Siempre prefiero los nombres positivos, para evitar dobles negativos en el código. "No está inactivo" a menudo causa una doble toma al leer. "Está inactivo" siempre se puede escribir como "if (! Active)" mientras se aprovecha la semántica del lenguaje incorporado.

Fuente

2009-09-18 17:22:28

Mi preferencia personal:

Use prefijos como "es", "tiene", etc., para campos booleanos que hacen su propósito claro.
Siempre nombre variables en el afirmativo. Para Activo/Inactivo, lo llamaría IsActive.
No hagas que un campo sea nulo a menos que realmente tengas un propósito específico al hacerlo.

En su caso de uso específico, el campo debe llamarse IsPublic o IsPrivate, cualquiera que sea el nombre que resulte en una respuesta verdadera cuando el usuario marque la casilla de verificación.

Fuente

2009-09-18 17:24:04 richardtallent

+1 para "casilla de verificación verdadera" que equivale a "base de datos verdadera" –

... ¿y qué hay de los negativos incorporados del diseño como "línea de bloqueo"? El dispositivo está inactivo si la línea de bloqueo es alta. isLockedOut significa prácticamente isDeviceInactive. Pero cuando pruebo la línea de bloqueo, estoy interesado en isLockoutActive ... o, isWorkingCorrectly o isInFaultMode? –

SF, no estoy seguro de seguir su lógica aquí, pero creo que puede haber excedido el propósito de un valor booleano y puede necesitar un campo de estado, con una lista de búsqueda de posibles valores de estado. La respuesta de OMG Ponies es la correcta en ese caso. – richardtallent

Siempre use nombres positivos.

Si usa nombres negativos, muy rápidamente entra en doble negación. No es que la doble negación sea una cirugía de cohete, pero es un ciclo cerebral y esos son valiosos :)

Fuente

2009-09-18 17:29:00 Stefan

Siempre use positivo.

Es más simple.

Tome usando la negación al extremo lógico: si InActive es mejor que Active, entonces ¿por qué no InInactive, o InInInactive?

Porque sería menos simple.

Fuente

2009-09-18 17:33:21

La forma correcta de manejar estas situaciones es crear una tabla para alojar los valores asociados con la columna y crear una relación de clave externa entre las dos tablas.IE:

WIDGETS tabla:

WIDGET_ID
WIDGET_STATUS (fk)

WIDGET_STATUS_CODES tabla:

WIDGET_STATUS_CODE (pk)
DESCRIPTION

Si es posible, WIDGET_STATUS_CODE habría una clave natural (IE: ACT para "activo", INA para "inactivo"). Esto haría que los registros fueran más legibles para las personas, pero no siempre es posible, por lo que utilizaría una clave artificial/sustituta (como un número automático/secuencia/etc.).

que quieres hacer esto porque:

Es legible por lo estado indica (que era la pregunta original)
prueba de futuro en la necesidad de definir/usar más estados de
proporciona integridad referencial por lo alguien no pudo establecer el valor en 2, 3, 4, etc.
El espacio es barato; hay nada eficiente en cuanto a permitir malos datos

Fuente

2009-09-18 17:33:42

Esto es mucho menos eficiente que un simple campo de bit. ¿Cuál es la justificación para hacer esto frente a un campo de bit simple para una respuesta booleana simple? – richardtallent

(a) La legibilidad humana de tablas desnudas no es, en mi humilde opinión, un objetivo de buen diseño de la base de datos. De lo contrario, nunca usaríamos claves sustitutivas, y nuestras bases de datos pasarían toda su vida haciendo comparaciones de cadenas. – richardtallent

(b) En principio, estoy de acuerdo con w/r/t a prueba de futuro para más valores, pero SÓLO si hay un posible estado que NO sea de las opciones existentes. Nombrar un campo algo genérico como "Estado" cuando realmente tiene que ver * solo * con el modo Activo/Inactivo invita a futuros abusos por calzar atributos ortogonales. Eventualmente, esto fuerza el diseño hacia una relación m: n que se asemeja a una nube de etiquetas mal escrita. No estoy en contra de las nubes de etiquetas en general, pero rompen la normalización, y eso tiene consecuencias para el diseño. – richardtallent

yo no estaría de acuerdo con algunas de las otras respuestas, pero sin duda evitar la respuesta incorrecta que no es poner en dobles negaciones siempre

Fuente

2009-09-18 17:54:59 leora

-1

tratar de evitar campos booleanos en bases de datos alltogether.

Una, la RM tiene una forma mucho mejor de representar información con valores verdaderos que mediante campos booleanos: mediante la presencia de una tupla en una tabla.

Dos campos booleanos son discriminadores muy malos al realizar consultas. Es casi una completa locura indexarlos, por lo que, al realizar consultas, la presencia de campos booleanos no proporciona ningún beneficio.

Fuente

2009-09-18 20:49:40

Los valores booleanos pueden ser discriminadores pobres, pero eso depende * completamente * de la distribución de los valores 0 y 1. Como cualquier índice, indexar un campo de bit agrega un elemento de direccionamiento de búsqueda de tabla si no es la columna de primer orden en un índice agrupado (que no recomiendo), pero la indexación * evita * un escaneo de tabla, por lo there * is * un beneficio de rendimiento. Mientras tanto, usar un FK en otra tabla con un solo valor tiene exactamente la limitación de rendimiento como un campo de bit indexado, y por la misma razón, pero las uniones agregan una sobrecarga adicional sustancial frente a una búsqueda de índice de bit. – richardtallent

nombres de los campos booleanos positivo o negativo

Respuesta

Cuestiones relacionadas