¿Hay razones para no almacenar valores booleanos en SQL como tipos de datos de bits?

Lo que normalmente sucede en el camino es que alguien quiere agregar también un tal vez a sí y no, si tiene un poco, entonces ahora tiene que cambiar todo su código a tinyint

Si tuvieras tinyint para empezar, entonces no lo tienes.....créeme, esto sucede más de lo que piensas

Los veo a menudo almacenados como enteros sin restricciones a los valores límite a 0 y 1, y como cuerdas con cosas como T / F, Verdadero / Falso, sí / no, etc., de nuevo sin restricciones. ¿No es mejor almacenarlos como bits y no tiene que preocuparse por adicional ¿restricciones?

¡Sí!

¿Qué me estoy perdiendo aquí?

En realidad debería ser "¿qué no me estoy perdiendo aquí?"y la respuesta sería: sentido común .

Cuando quiero booleanos en la base de datos siempre uso el tipo de datos de bits. En SQL pueden ser NULL. Pero al ejecutar su programa tendrá que considerar que un bool (por ejemplo, en C#) es un tipo de valor que en este caso no puede ser NULL. Tendrás que comparar con el Sistema.Valor DBNull.

Siempre almacenamos los datos como un bit, es pequeño, y lo más importante es que este es el caso para el que está diseñado.

Hemos tenido momentos en los que el usuario final iba a trabajar con los datos directamente, y para ellos, Sí/No o Y/N era más legible. En este caso, acabamos de crear una vista que reflejaba la visualización de datos más amigable.

BIT es el tipo de datos que normalmente se usa para almacenar valores BOOLEANOS. Simplemente porque si el BIT es 1 entonces su verdadero y 0 entonces su falso. Es así de simple.

Algunas razones para no hacerlo incluyen:

No todas las bases de datos tienen un tipo de datos de bits, por lo que se usa int para poder usar backends diferentes

En algunas bases de datos no se puede indexar un campo de bits.

Y a menudo lo que tienes no es verdaderamente verdadero/falso, sí/no sin otras posibilidades. Por ejemplo, puede tener un campo de bits para el estado que significa algo como abierto o cerrado. Pero más tarde te das cuenta de que necesitas cancelar como un estado también.

Utilice Enum si tiene más de dos estados.

Una razón es que la gente no sabe sobre bit o piensa que y/n es más simple para formatear. otra razón es que a veces piensas: hmm tal vez con el tiempo esto será más que un campo bool. y lo haces por si acaso.

No te estás perdiendo nada:)

Creo que la tercera forma de normalización indicaría que debe tener una tabla que almacene los valores True y False, y haga referencia a eso. Asegúrese de hacer eso con sus fechas también!

Pero ¿quién se adhiere completamente a 3NF de todos modos? ;)

Uso mucho bit. Pero a veces quiero tener la capacidad de devolver false - o muchos valores de true (como mensajes de error). Así que si utilizo un int en lugar de booleano puedo doe algo como:

0 = False 1 = Contraseña incorrecta 2 = El nombre de usuario no existe. 3 = Cuenta bloqueada-a muchos intentos fallidos. 4 = Cuenta desactivada.

Y así sucesivamente.