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

¿Existen 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?¿Hay razones para no almacenar valores booleanos en SQL como tipos de datos de bit?

Fuente

2009-04-22 anopres

Siempre había quedo con el tipo de datos más pequeño que pueda para almacenar esto.

SQLServer: BIT
Oracle: NÚMERO (1) (o BOOLEANA en PL/SQL)
MySQL: TINYINT (mapas IIRC BOOLEANAS a esto automáticamente)

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

Fuente

2009-04-22 13:49:54 Powerlord

Re. "tipo de datos más pequeño disponible": los valores BIT de SQL Server no son realmente un ancho, sino múltiplos de un byte completo. Sin embargo, más de un BIT en la misma tabla se colapsó en el mismo almacenamiento. – Tomalak

MySQL también admite el tipo BIT, y sus requisitos de almacenamiento funcionan exactamente como explicó Tomalak. –

@Chad: columnas MySQL BIT son claramente diferentes de las columnas SQLServer BIT; un campo SQL Server BIT almacena solo un valor, y los campos BIT se combinan juntos cuando se almacenan si hay más de uno. Un campo BIT MySQL es una máscara de bits con 1 a 64 bits (según la declaración). – Powerlord

Una de las razones 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.

usted no está perdiendo nada :)

Fuente

2009-04-22 13:48:53

lo que normalmente ocurre en el camino es que alguien quiere añadir también un tal vez para sí y no, si usted tiene un poco, entonces ahora hay que cambiar todo el código a tinyint

si tuviera tinyint para comenzar con entonces no ... crea que esto sucede más de lo que piensas

Fuente

2009-04-22 13:50:11 SQLMenace

+1 Me encontré con esta situación antes ... no a menudo, pero ha criado su cabeza fea. – mattruma

Pensado, a menudo no es tan difícil refactorizar. – mattruma

+1 Me parece que puede cambiar de un bool a un estado o columna de estado en algún momento de su vida. – cgreeno

Cuando quiero booleanos en la base de datos siempre uso el tipo de datos de bit. En SQL, pueden ser NULL. Pero cuando ejecuta 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.

Fuente

2009-04-22 13:50:19 rguerreiro

¿No podría simplemente designar la variable como Nullable , podría manejar el valor NULL? – mattruma

lo convierten en NOT NULL en SQL ....... create table bla (bit de respuesta no nulo) – SQLMenace

el problema es lo que admite ADO.NET o algún otro marco de acceso a datos. si permite Nullable ¡estamos bien! – rguerreiro

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.

Fuente

2009-04-22 13:51:00 mattruma

Mis últimos 2 trabajos después de entregar mi primer proyecto me hicieron retroceder y cambiar todos los 0 a "N" y 1 a "T". Ambos tenían la misma razón. "Nunca podemos recordar cuál es cuál". Pensé que 0 = falso estaba computando 101 pero aparentemente es bastante común no saber. O tal vez es una señal de que no estoy escogiendo buenos lugares para trabajar. – dwidel

los veo a menudo se almacenan como enteros sin restricciones a los valores límite de 0 y 1, y como cadenas 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 las restricciones adicionales ?

Sí!

¿Qué es lo que falta aquí?

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

Fuente

2009-04-22 13:51:11 TheTXI

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.

Fuente

2009-04-22 13:51:41 TStamper

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úrate de hacer eso con tus fechas también!

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

Fuente

2009-04-22 14:07:09

Es posible que desee encontrar una fuente diferente para su definición de Tercera forma normal. No hay nada que indique que todos los valores en todas las columnas también se deben almacenar en tablas en alguna parte. –

-1

Uso bit 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 booleano, 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í sucesivamente.

Fuente

2009-04-22 14:33:23

Entonces eso no es un booleano. Es un valor de código. Un booleano por definición es verdadero o falso y no hay múltiples definiciones de verdadero. –

Como dije, uso mucho el bit. Luego di una solución alternativa. Y si lees mi publicación, dije que a veces utilizo un int en lugar de un booleano. –

Algunas de las razones para no hacerlo son:

No todas las bases de datos tienen un tipo de datos bit por lo que utilizar int en lugar de ser capaz de utilizar backends diferentes personas

En algunas bases de datos que no pueden indexar un campo de bits.

Y a menudo lo que tiene no es realmente 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.

Fuente

2009-04-22 18:51:34 HLGEM

Use Enum si tiene más de dos estados.

Fuente

2010-01-07 09:36:40 sarvesh

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

Respuesta

Cuestiones relacionadas