Uso de booleanos en una base de datos

7

Estoy usando Visual Studio 2013, .Net 4.5 y SQL Management Studio 2012. Tengo una tabla que rastrea las oficinas en mi base de datos. En el lado de la aplicación hay algunas reglas de visualización con respecto al diseño de las oficinas. Si se remodela un edificio, se cambia el nombre de las oficinas y las oficinas antiguas pueden quedar inactivas. Es importante no eliminar las oficinas inactivas para realizar un seguimiento de los elementos del historial.

Iba a colocar una columna booleana en la tabla de mi base de datos para decidir si una oficina está activa. Si la columna isActive es igual a True , la oficina podrá seleccionarse para que se le agreguen elementos.

Uno de mis colegas está muy en contra del uso de campos booleanos en la base de datos, pero no ha proporcionado ninguna razón sólida para no usarlos. Me han dicho "no lo hagas" y "es difícil de usar", pero nada de lo que considero realmente sustancial. Creo que se ha encontrado con una situación donde la base de datos se configuró inicialmente para tener valores booleanos y el cliente ha agregado opciones a un campo (algo que era verdad falso, ahora puede ser A, B o C). Se ha sugerido que use un varChar(1) con una "Y" o "N" en lugar de valores booleanos.

Entonces, lo que me pregunto es que, dado el escenario en el que no hay forma de que una oficina pueda ser otra cosa que no sea "activa" o "inactiva", ¿hay alguna razón por la que se deba evitar este valor como booleano?

    
pregunta rogerdeuce 10.03.2016 - 16:59

3 respuestas

9

Recibo el punto de vista de sus compañeros de trabajo sobre la posibilidad de algunos casos en los que un bool podría llegar a ser más que true o false , en algunos casos, pero no realmente este. Pero sugeriría mucho contra ir por la ruta varchar . Use una tabla de búsqueda con valores válidos y un integer id con una restricción única en los valores válidos, o una enumeración como se sugirió en los comentarios / otras respuestas.

tenemos "aparentemente" campos de sonido bool en toda nuestra base de datos, pero en realidad son cadenas. Con nuestra aplicación, que es de 4 niveles, con un parámetro de cadena que se pasa a través de los niveles, usted no tiene (potencialmente) idea de cuáles son los valores "válidos" de la cadena.

ejemplo:

useMaster varchar(1).

Creo que esto se ajusta mucho mejor como bool que una cadena. Es "maestro" o "transacción" en mi caso. Sin embargo, debido a que estamos usando una varchar, ¿cuál es mi nivel de proc 4 en espera de significar maestro? No tengo idea de la interfaz de usuario ¿Es "Y" para sí? es "T" para verdad? Si hubiera adivinado cualquiera de esos, habría estado equivocado, porque en realidad era "M" para el maestro. En mi caso básicamente tenemos:

If (@userMaster = 'M')
    // use master
else
    // use transaction

Ninguna de las opciones que había imaginado era un valor válido para obtener el master como quería. Tengo que profundizar en 4 niveles de código para determinar qué esperaba realmente el proceso.

cadenas mágicas son bad Recomiendo altamente que no usándolos.

    
respondido por el Kritner 10.03.2016 - 17:18
4
  

¿hay alguna razón por la que se deba evitar representar este valor como un booleano?

No.

Dada la situación que describió, un booleano es un buen candidato para el estado activo / inactivo.

Alternativa:

Sin embargo, le sugiero que utilice un campo de marca de tiempo / fecha y hora para registrar su estado activo. Usted mencionó que desea mantener un historial de oficinas inactivas. Si tiene una columna llamada activeTo con el tipo datetime que permite valores nulos, puede usar ese campo para saber si la oficina sigue siendo válida.

  • la fecha nula o futura está activa;
  • cualquier fecha en el pasado está inactiva;

Esto le permitirá saber cuándo se hizo inactiva la oficina.

Alternativa 2:

También puede mantener todas sus oficinas en 1 tabla y tener otra tabla para representar las activas. Sólo una columna de identificación. Puedes usar JOIN para filtrar las tablas inactivas. No he usado este enfoque, así que no sé si hay algún problema que me esté faltando.

Alternativa 3:

Como alguien más sugirió, podría agregar una tabla para contener todos los valores posibles para el estado de la oficina. Esto le permite actualizar las posibilidades de muchas maneras y proporcionar al usuario una representación más significativa que solo Y o T.

Le sugiero que mire varias opciones e intente hacer la mejor suposición que pueda hacer. Todos ellos tienen ventajas y compensaciones. El contexto y el equilibrio son importantes.

    
respondido por el Alexandru Ungureanu 10.03.2016 - 22:46
3

El uso de varchar(1) para algo que es uno de dos valores es tonto: para eso es un campo bit .

Sin embargo, si el requisito cambia alguna vez y se necesitan valores de estado adicionales, puede ser mejor usar una enumeración en el código y almacenar el valor como un entero. Si lo hace de esta manera, no necesitará volver a cambiar la estructura de la base de datos para almacenar los nuevos valores.

    
respondido por el user1666620 10.03.2016 - 17:05

Lea otras preguntas en las etiquetas