Biorąc pod uwagę, że pola bitowe są po prostu binarnymi reprezentacjami danych i należy je przeszukiwać w nieco „dziwny” sposób.
Czy rzeczywiście zapewnia jakąkolwiek korzyść przy użyciu pola bitowego dla wartości logicznej? Z tego, co widzę, wydaje się sugerować, że przestrzeń jest jedyną prawdziwą korzyścią.
Odpowiedzi:
Osobiście BOOLEANużyłbym wartości boolean. Pamiętaj jednak, że zastrzeżenie, że w MySQL BOOLEANjest tylko synonimem TINYINT(1) [src] .
To oczywiście oznacza, że możesz mieć wartości inne niż 0 lub 1, jeśli nie będziesz ostrożny. Aby tego uniknąć, możesz użyć aliasów TRUEoraz FALSEpodczas wstawiania i aktualizowania danych, ponieważ mapują one odpowiednio na 1 i 0.
W celu zachowania kompletności przed wersją 5.0.3 BITbył także synonimem TINYINT(1).
Jeśli dobrze to rozumiem, BOOLEAN zawsze używa 1 bajtu na kolumnę, ale BIT (n) użyje tylko kilku bajtów, które są potrzebne do utrzymania podanej liczby bitów.
Tak więc BIT może zaoszczędzić trochę miejsca, ale BOOLEAN jest łatwiejszy w obsłudze, jeśli potrzebujesz zapytać o nie za pomocą SQL.
Gdybym miał zestaw flag, które były rozumiane przez aplikację i przechowywane w jednym polu w aplikacji, wtedy szukałbym użycia BIT (n). Jednak gdybym miał kolumny, które wymagałyby zapytania z SQL, użyłbym BOOLEAN.
Przykładem może być aplikacja, która używa flag do rejestrowania, w których tygodniach zdarzenie powinno się uruchamiać, z odrobiną tygodniowo, wynoszącą 1, jeśli zdarzenie działa w danym tygodniu. Jeśli dane miałyby być łatwo wyszukiwane w bazie danych, byłyby „znormalizowane” w dwóch tabelach, ale gdyby dane musiały być tylko przechowywane w bazie danych, najlepiej przechowywać je w formie, w której aplikacja je wykorzystuje w.