Tinyint vs Bit?

No quiero iniciar una guerra religiosa aquí, pero parece haber dos escuelas de pensamiento sobre cómo representar valores booleanos en una base de datos. Algunos dicen que bites el tipo de datos apropiado, mientras que otros sostienen que tinyintes mejor.

Las únicas diferencias que conozco son estas:

• bit: el tamaño de almacenamiento es de 1 bit, los valores posibles son 0 o 1
• tinyint: el tamaño de almacenamiento es de 1 byte, los valores posibles son 0-255

¿Qué tipo de datos es mejor cuando necesita representar valores booleanos? ¿ tinyintVale la pena la sobrecarga adicional "por si acaso" necesita valores> 1?

Cuando agrega una columna de bits a su tabla, ocupará un byte completo en cada registro, no solo un bit. Cuando agrega una segunda columna de bits, se almacenará en el mismo byte. La columna del noveno bit requerirá un segundo byte de almacenamiento. Las tablas con una columna de 1 bit no obtendrán ningún beneficio de almacenamiento.

Tinyint y bit se pueden hacer que funcionen, he usado ambos con éxito y no tengo muchas preferencias.

Bit ... a menos que pertenezcas al clan "verdadero / falso / archivo no encontrado"

En caso de que no haya obtenido la referencia ...

Y en el caso de Linq2SQL, bit funciona con verdadero / falso, lo que facilita la programación. Ambos tienen ventajas.

Y también hay que tener en cuenta el mantenimiento de la programación. ¿Qué sucede si usted (o un programador en prácticas junior) utiliza un 2, 3, 25, 41, 167, 200, etc.? ¿Dónde está eso documentado? Los bits se autodocumentan y son bastante universales.

Utilizo bits cuando es apropiado. Además de ser semánticamente del tipo correcto (¡la semántica cuenta!), Varios campos de bits (hasta 8) en una sola fila (en SQL Server, de todos modos) se pueden consolidar en un solo byte de almacenamiento. Después del octavo, se necesita un byte adicional para los siguientes 8, y así sucesivamente.

Referencias:

• SQL 2000
• SQL 2005
• SQL 2008

Para usuarios de MySql: por qué no debería usar columnas BIT en MySQL

Una publicación anterior de StackOverflow: ¿Cuál es la diferencia entre BIT y TINYINT en MySQL?

Al agregar una nueva columna "BOOL", MySQL realmente usa TINYINT.

Me quedaría con BOOL (también conocido como TINYINT ) y seguiría adelante con la vida.

Booleano, por definición, permite solo dos valores. ¿Por qué necesitarías algo más que un bit para esto? si necesita una lógica de tres (o más) estados, utilice un tipo de datos más grande, pero me quedaría (y lo haré) con los campos de bits para la lógica booleana estándar.

Utilizo bit porque me ahorra tener que usar una restricción de verificación y porque mi ORM convertirá automáticamente bit en un booleano anulable (C #), que aprecio mucho una vez que codifico.

Espacio cero para falso

Cualquiera que sea su elección, puede configurarlo en NULLlugar de 0y no ocupará espacio adicional (ya que la base de datos casi siempre tiene una NULLbandera para cada campo de cada fila, simplemente allí; más información aquí ). Si también se asegura de que el valor predeterminado / más probable sea false, ¡ahorrará aún más espacio!

Algo de espacio para la verdad

El valor a representar truerequiere el espacio definido por el tipo de campo; el uso BITsolo ahorrará espacio si una tabla tiene varias columnas de este tipo, ya que usa un byte por cada 8 campos (frente a lo TINYINTque usa un byte por campo).

TINYINTtiene la ventaja de permitirle personalizar una máscara de bits de 8 valores sin preocuparse por administrar un montón de columnas adicionales, y la búsqueda es teóricamente más rápida (un campo de un solo número entero frente a varios campos de bits). Pero hay algunas desventajas, como un orden más lento, elementos elegantes de indexación cruzada y la falta de nombres de campo. Lo cual para mí es la mayor pérdida; su base de datos requeriría documentación externa para anotar qué bits hicieron qué en qué máscaras de bits.

En cualquier caso, evite la tentación de utilizar TEXTcampos para almacenar valores booleanos o conjuntos de ellos. La búsqueda en el texto es mucho más trabajo para el servidor y los esquemas de nombres arbitrarios como "encendido, apagado, apagado" pueden dañar la interoperabilidad.

Intenté agrupar en bit (SQL Server 2k5) y funcionó bien para mí. Me gusta usar el tipo de datos correcto para la aplicación. Si es un campo verdadero / falso, entonces lo que uso es bit ...

Todas estas discusiones teóricas son geniales, pero en realidad, al menos si está usando MySQL y realmente para SQLServer también, es mejor quedarse con datos no binarios para sus booleanos por la sencilla razón de que es más fácil trabajar con ellos cuando están generando datos, consultando, etc. Es especialmente importante si está intentando lograr interoperabilidad entre MySQL y SQLServer (es decir, sincroniza datos entre los dos), porque el manejo del tipo de datos BIT es diferente en los dos. Entonces, en la práctica, tendrá muchas menos molestias si se queda con un tipo de datos numérico. Recomendaría que MySQL se quede con BOOL o BOOLEAN, que se almacena como TINYINT (1). Incluso la forma en que MySQL Workbench y MySQL Administrator muestran el tipo de datos BIT no es agradable (es un pequeño símbolo para datos binarios).

No creo que lo vi mencionado anteriormente, pero existe el problema de no poder agregar columnas BIT (por ejemplo, MIN, MAX y especialmente SUM). Acabo de probar con 2008 y el problema sigue ahí. Esa es la razón más importante por la que uso tinyint últimamente, la otra es que me gusta la escala de tinyint, siempre es un fastidio cuando la bandera de bits de "dos valores" de repente necesita más valores posibles.

Construimos todas nuestras tablas con un campo "vector" int. Luego usamos ese campo como una colección de 32 bits que podemos asignar para cualquier propósito. (Potencialmente usando un grupo de bits para un conjunto de estados). Evita que tengamos que seguir agregando campos de bandera si lo olvidamos.

@Kevin: Creo que puedes usar group byen campos de bits (SQL Server 2005):

declare @t table (
    descr varchar(10),
    myBit1 bit, 
    myBit2 bit
)
insert into @t values ('test1', 0, 1)
insert into @t values ('test2', 1, 0)
insert into @t values ('test3', 1, 1)
insert into @t values ('test4', 0, 0)

select myBit1, count(myBit1) from @t group by myBit1
select myBit2, count(myBit1) from @t group by myBit2

Resultados:

myBit1 
------ -----------
0      2
1      2

myBit2 
------ -----------
0      2
1      2

TinyInt es mi preferencia. Entonces, al hacer recuentos agregados contra el campo, no tiene que lanzarlo. Además, algunos lenguajes front-end interpretan un Bit de manera diferente a otros, y el uso de TinyInt hace que las comprobaciones de validación sean universales para cualquier lenguaje front-end.

Si está utilizando MySQL, no se recomienda utilizar el tipo de datos BIT: http://www.xaprb.com/blog/2006/04/11/bit-values-in-mysql/

Me gusta usar char (1) con 'T' o 'F'. Sí, se puede abusar de otros valores, pero al menos es fácil de ver en informes u otros lugares donde es más difícil trabajar con valores de bits o binarios.