Dado que los campos de bits son solo representaciones binarias de datos y deben consultarse de forma ligeramente "extraña".
¿Realmente proporciona algún beneficio usando un campo de bit para un valor booleano? Por lo que puedo ver, parece sugerir que el espacio es el único beneficio real.
Respuestas:
Personalmente, usaría el BOOLEANvalor booleano. Pero tenga en cuenta la advertencia de que en MySQL, BOOLEANes solo un sinónimo de TINYINT(1) [src] .
Esto, por supuesto, significa que puede tener valores distintos de 0 o 1 si no tiene cuidado. Para evitar esto, puede usar los alias TRUEy FALSEal insertar y actualizar datos, ya que se asignan a 1 y 0 respectivamente.
En aras de estar completo, antes de 5.0.3, BITtambién era sinónimo de TINYINT(1).
Si lo entiendo correctamente, BOOLEAN siempre usa 1 byte por columna, pero BIT (n) usará los pocos bytes necesarios para contener el número dado de bits.
Por lo tanto, BIT puede ahorrar algo de espacio, pero es más fácil trabajar con BOOLEAN si necesita consultarlos con SQL.
Si tuviera un conjunto de indicadores que una aplicación entendiera y almacenara en un solo campo en la aplicación, entonces buscaría usar BIT (n). Sin embargo, si tuviera columnas que debían consultarse desde SQL, estaría usando BOOLEAN.
Un ejemplo sería una aplicación que usara marcas para registrar en qué semanas debería ejecutarse un evento, con un bit por semana, siendo 1 si el evento se ejecuta en la semana dada. Si los datos fueran fáciles de consultar en una base de datos, se "normalizaría" en dos tablas, pero si los datos solo necesitaran almacenarse en la base de datos, entonces es mejor conservarlos en la forma en que la aplicación los usa. en.