Typy logiczne: BIT vs INT

BIT zajmuje mniej miejsca i sprawdza się dla wartości logicznych, INT jest właściwszy dla pełnych liczb całkowitych.

BIT i INT jako różne modele danych

Typ BIT służy do przechowywania wartości logicznych, czyli informacji, która ma ograniczony zbiór stanów, na przykład „włączone” albo „wyłączone”, „aktywne” albo „nieaktywne” oraz „spełnia warunek” albo „nie spełnia warunku”. Typ INT przeznaczony jest natomiast do pełnych liczb całkowitych. W zależności od konkretnego silnika SQL typ BIT może przyjmować wartości logiczne, wartości liczbowe odpowiadające stanom prawda i fałsz albo również stan NULL oznaczający brak wartości. Dokładna składnia oraz sposób zapisu zależą od używanego systemu bazodanowego.

Porównanie BIT z INT nie sprowadza się wyłącznie do liczby zajmowanych bajtów. Najważniejsza jest zgodność typu z sensem danych. Kolumna określająca, czy konto jest aktywne, powinna mieć typ logiczny, ponieważ jej dozwolone wartości są ograniczone. Kolumna przechowująca liczbę prób logowania, numer elementu albo ilość sztuk wymaga typu całkowitoliczbowego. Użycie INT do wartości logicznej może działać w prostym zapytaniu, ale pozwala zapisać liczby, które nie mają znaczenia dla danego pola, utrudnia walidację i zaciera model danych.

Rozmiar zapisu i ograniczenia wartości

BIT zwykle pozwala ograniczyć reprezentację pola do wartości logicznych, jednak nie należy automatycznie zakładać, że każda kolumna BIT zajmuje dokładnie jeden bit na dysku. Silnik może pakować kilka pól bitowych razem, przechowywać je w jednostkach bajtowych albo stosować własne reguły wyrównania. Z tego powodu rzeczywisty rozmiar tabeli zależy od implementacji, liczby kolumn, indeksów, układu rekordu i pozostałych typów danych. Stwierdzenie, że BIT jest przeznaczony do wartości logicznych i zwykle oszczędniejszy od INT, jest bezpieczniejsze niż podawanie jednej uniwersalnej liczby bajtów.

INT ma znacznie większy zakres wartości niż typ logiczny. W wielu popularnych silnikach SQL liczby całkowite o nazwie INT są przechowywane jako typ czterobajtowy, lecz zakres i szczegóły konwersji trzeba potwierdzić w dokumentacji konkretnego produktu. INT może reprezentować wartości ujemne i dodatnie, dlatego nadaje się do liczników, identyfikatorów oraz wyników obliczeń całkowitoliczbowych. Nie powinien zastępować BIT tylko dlatego, że aplikacja aktualnie zapisuje w nim 0 i 1. Jeżeli domena danych jest logiczna, ograniczenie jej do tego znaczenia poprawia czytelność schematu i zmniejsza ryzyko błędnego zapisu.

Trzeba również rozróżnić wartość 0 lub 1 od NULL. NULL nie jest trzecią liczbą ani prostym odpowiednikiem „fałsz”; oznacza brak znanej wartości. W zapytaniach SQL może to prowadzić do logiki trójwartościowej. Warunek WHERE flaga = 0 nie zwróci wierszy, w których flaga ma NULL. Jeżeli brak wartości ma być traktowany jako osobny stan, należy świadomie zaprojektować kolumnę i warunki, na przykład przez użycie IS NULL albo odpowiedniego wyrażenia zastępującego NULL.

Wpływ typu na zapytania i aplikację

Dobór BIT albo INT wpływa na sposób filtrowania, sortowania, agregowania i przekazywania danych między bazą a aplikacją. Dla pola BIT typowy jest warunek sprawdzający stan logiczny, natomiast dla INT naturalne są porównania zakresów, sumowanie i inkrementacja. Operacja zwiększenia licznika o jeden ma sens dla INT, ale dla BIT wskazuje zwykle na błąd modelu danych. Podobnie sortowanie wartości logicznych według 0 i 1 może być technicznie możliwe, lecz często nie wyraża istotnej kolejności biznesowej.

Konwersje między typami powinny być jawne albo wykonywane zgodnie z zasadami danego silnika. Aplikacja może otrzymywać BIT jako wartość logiczną, liczbę lub inny typ zależnie od sterownika i biblioteki dostępu do danych. Jeżeli kod oczekuje zawsze liczby, a warstwa pośrednia zwraca wartość typu bool, mogą pojawić się błędy serializacji, niezgodności parametrów albo niejednoznaczne warunki. Warto sprawdzić definicję tabeli, typ parametrów zapytania, mapowanie ORM oraz wartości zwracane przez sterownik zamiast zakładać, że 0 i 1 będą obsługiwane identycznie w każdej warstwie.

W przypadku indeksów mała liczba możliwych wartości BIT może ograniczać użyteczność prostego indeksu, zwłaszcza gdy jedna wartość występuje w większości wierszy. Nie oznacza to jednak, że indeksowanie kolumn logicznych jest zawsze błędne. Znaczenie ma selektywność, rozmiar tabeli, częstotliwość zapytań oraz plan wykonania. Kolumna INT może mieć większą różnorodność wartości i dzięki temu lepiej zawężać wynik, ale sam większy zakres typu nie gwarantuje szybszego działania. Decyzję należy opierać na rzeczywistych zapytaniach i analizie planów, nie na samej nazwie typu.

Dobór typu podczas przeglądu komputera i aplikacji

Przy analizie problemu z aplikacją warto najpierw ustalić, jakie znaczenie ma dana kolumna, a dopiero potem porównywać typy. Należy sprawdzić schemat tabeli, wartości domyślne, dopuszczalność NULL, ograniczenia integralności oraz miejsca, w których dane są zapisywane i odczytywane. Jeżeli pole logiczne zawiera wartości inne niż przewidziane przez projekt, problem może wynikać z błędnej konwersji, nieprawidłowego formularza, starej migracji albo niespójnego kodu aplikacji. Jeżeli kolumna INT przechowuje wyłącznie 0 i 1, sama obserwacja danych nie przesądza jeszcze o konieczności zmiany typu; trzeba uwzględnić zapytania, integracje i zgodność wsteczną.

Zmiana INT na BIT albo odwrotnie może wymagać modyfikacji zapytań, indeksów, procedur, kodu aplikacji i testów. Szczególnej uwagi wymagają wartości NULL, dane spoza oczekiwanego zakresu oraz różnice między środowiskami korzystającymi z różnych silników SQL. Przed zmianą schematu należy wykonać kopię danych, sprawdzić zależności i przetestować operację na środowisku kontrolnym. W razie problemów z komputerem, aplikacją bazodanową lub działaniem programu Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów.