Dado que os campos de bits são apenas representações binárias de dados e precisam ser consultados de maneira um pouco "estranha".
Ele realmente oferece algum benefício usando um campo de bits para um valor booleano? Pelo que pude ver, parece sugerir que o espaço é o único benefício real.
Respostas:
Pessoalmente, eu usaria o BOOLEANvalor booleano. Mas tenha em mente a ressalva de que, no MySQL, BOOLEANé apenas um sinônimo de TINYINT(1) [src] .
Obviamente, isso significa que você pode ter valores diferentes de 0 ou 1 se não for cuidadoso. Para evitar isso, você pode usar os aliases TRUEe FALSEao inserir e atualizar dados, como aqueles mapeados para 1 e 0, respectivamente.
Por uma questão de estar completo, antes da versão 5.0.3, BITtambém era sinônimo de TINYINT(1).
Se eu entendi direito, o BOOLEAN sempre usa 1 byte por coluna, mas o BIT (n) usa o mínimo de bytes necessário para armazenar o número especificado de bits.
Portanto, o BIT pode economizar algum espaço, mas é mais fácil trabalhar com o BOOLEAN se você precisar consultá-los com SQL.
Se eu tivesse um conjunto de sinalizadores que foram entendidos por um aplicativo e armazenados em um único campo no aplicativo, procuraria usar o BIT (n). No entanto, se eu tivesse colunas que precisassem ser consultadas do SQL, eu estaria usando o BOOLEAN.
Um exemplo seria um aplicativo que usasse sinalizadores para registrar em que semanas um evento deve ser executado, com um pouco por semana, sendo 1 se o evento for executado na semana especificada. Se os dados fossem facilitados para consulta em um banco de dados, eles seriam "normalizados" em duas tabelas, mas se os dados precisassem ser armazenados apenas no banco de dados, é melhor mantê-los no formato que o aplicativo os utiliza. dentro.