numerico - ¿Hay razones para no almacenar valores booleanos en SQL como tipos de datos de bit?

tipo de dato numerico sql

Question

¿Hay razones para no almacenar valores booleanos en SQL como tipos de datos de bit sin NULL? Los veo a menudo almacenados como enteros sin restricciones para limitar los valores a 0 y 1, y como cadenas con cosas como T / F, Verdadero / Falso, sí / no, etc., de nuevo sin restricciones. ¿No es mejor guardarlos como bits y no tener que preocuparse por restricciones adicionales? ¿Que me estoy perdiendo aqui?

Answer 1

Los veo a menudo almacenados como enteros sin restricciones para limitar los valores a 0 y 1, y como cadenas con cosas como T / F, Verdadero / Falso, sí / no, etc., de nuevo sin restricciones. ¿No es mejor guardarlos como bits y no tener que preocuparse por restricciones adicionales?

¡Sí!

¿Que me estoy perdiendo aqui?

En realidad, debería ser "¿qué es lo que NO estoy perdiendo aquí?" y la respuesta sería: sentido común .

Answer 2

Algunas razones para no hacerlo incluyen:

No todas las bases de datos tienen un tipo de datos de bit, por lo que utiliza int en su lugar para poder usar diferentes backends

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

Y a menudo lo que tienes no es verdaderamente verdadero / falso, sí / no sin otras posibilidades. Por ejemplo, puede tener un campo de bit para el estado que signifique algo así como abierto o cerrado. Pero luego te das cuenta de que también es necesario que canceles tu estado.

Answer 3

BIT es el tipo de datos normalmente utilizado para almacenar valores BOOLEAN. Simplemente porque si el BIT es 1, entonces es verdadero y 0, entonces es falso. Es así de simple.

Answer 4

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

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

Answer 5

Cuando quiero booleanos en la base de datos siempre uso el tipo de datos de bit. 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á que comparar con el valor de System.DBNull.

Answer 6

Siempre almacenamos los datos como un poco, es pequeño, y más importante, 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 refleje la visualización de datos más amigable.

Answer 7

Siempre me quedo con el tipo de datos más pequeño que puedo para almacenar esto.

• SQLServer: BIT
• Oracle: NUMBER (1) (o BOOLEAN en PL / SQL)
• MySQL: TINYINT (iirc BOOLEAN se asigna a esto automáticamente)

Editar: BOOLEAN de Oracle es solo PL / SQL, no definición de tabla. Respuesta actualizada para reflejar esto

Answer 8

Una razón es que la gente no sabe de poco o cree que y / n es más fácil de formatear. otra razón es que a veces piensas: hmm quizás con el tiempo esto será más que un campo bool. y lo haces int por si acaso.

no te estás perdiendo nada :)

Answer 9

Use Enum si tiene más de dos estados.

Answer 10

Yo uso un poco mucho Pero a veces quiero poder devolver valores falsos o muchos valores verdaderos (como los mensajes de error). Entonces, si uso un int en lugar de boolean, puedo hacer algo como:

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

Y así.

Answer 11

lo que normalmente sucede en el futuro es que alguien quiere agregar también un sí o no, si tiene un poco, ahora tiene que cambiar todo su código a tinyint

si tienes tinyint para empezar, entonces no ... créeme, esto sucede más de lo que crees