Tinyint vs Bit?

Nie chcę tu wywoływać wojny religijnej, ale wydaje się, że istnieją dwie szkoły myślenia o tym, jak przedstawiać wartości logiczne w bazie danych. Niektórzy twierdzą, że bitjest to odpowiedni typ danych, podczas gdy inni twierdzą, że tinyintjest lepszy.

Jedyne różnice, o których wiem, to:

• bit: rozmiar pamięci to 1 bit, możliwe wartości to 0 lub 1
• tinyint: rozmiar pamięci to 1 bajt, możliwe wartości to 0-255

Który typ danych jest lepszy, gdy chcesz przedstawić wartości logiczne? Czy tinyintwarte są dodatkowego narzutu „na wszelki wypadek”, którego potrzebujesz do wartości> 1?

Kiedy dodasz bitową kolumnę do swojej tabeli, zajmie ona cały bajt w każdym rekordzie, a nie tylko pojedynczy bit. Po dodaniu drugiej kolumny bitowej zostanie ona zapisana w tym samym bajcie. Dziewiąta kolumna bitowa będzie wymagać drugiego bajtu pamięci. Tabele z kolumną 1-bitową nie będą miały żadnej korzyści z przechowywania.

Tinyint i wędzidło mogą działać zarówno z powodzeniem, jak i bez silnych preferencji.

Bit ... chyba że należysz do klanu "prawda / fałsz / nie znaleziono pliku"

Na wypadek, gdybyś nie otrzymał referencji ...

A w przypadku Linq2SQL bit działa z prawdą / fałszem, co ułatwia programowanie. Obie mają zalety.

Należy również wziąć pod uwagę konserwację oprogramowania. Co się stanie, jeśli Ty (lub młodszy programista-stażysta) używasz 2, 3, 25, 41, 167, 200 itd.? Gdzie to jest udokumentowane? Bity same się dokumentują i są dość uniwersalne.

W razie potrzeby używam końcówek. Oprócz tego, że jest to poprawny semantycznie typ (liczba semantyki!), Wiele pól bitowych (do 8) w jednym wierszu (w każdym razie na serwerze SQL) można skonsolidować w jeden bajt pamięci. Po ósmej potrzebny jest dodatkowy bajt dla następnych 8 i tak dalej.

Bibliografia:

• SQL 2000
• SQL 2005
• SQL 2008

Dla użytkowników MySql - dlaczego nie powinieneś używać kolumn BIT w MySQL

Poprzedni post dotyczący StackOverflow: Jaka jest różnica między BIT i TINYINT w MySQL?

Dodając nową kolumnę „BOOL”, MySQL w rzeczywistości używa TINYINT.

Po prostu trzymałbym się BOOL (aka TINYINT ) i kontynuowałbym życie.

Boolean z definicji dopuszcza tylko dwie wartości. Dlaczego potrzebujesz do tego czegoś więcej niż jednego kawałka? jeśli potrzebujesz logiki z trzema (lub więcej) stanami, użyj większego typu danych, ale trzymałbym się (i robię) z polami bitowymi dla standardowej logiki boolowskiej.

Używam bitu, ponieważ oszczędza mi to konieczności używania ograniczenia sprawdzającego i ponieważ mój ORM automatycznie konwertuje bit na wartość logiczną dopuszczającą wartość zerową (C #), co bardzo doceniam po zakodowaniu.

Zero miejsca na fałsz

Cokolwiek wybierzesz, możesz ustawić NULLzamiast 0i nie zajmie to dodatkowego miejsca (ponieważ baza danych prawie zawsze ma NULLflagę dla każdego pola w każdym wierszu, po prostu tam siedzi; więcej informacji tutaj ). Jeśli również upewnisz się, że domyślną / najbardziej prawdopodobną wartością jest false, zaoszczędzisz jeszcze więcej miejsca!

Trochę miejsca na prawdę

Wartość do przedstawienia truewymaga przestrzeni zdefiniowanej przez typ pola; użycie BITpozwoli zaoszczędzić miejsce tylko wtedy, gdy tabela ma wiele takich kolumn, ponieważ wykorzystuje jeden bajt na 8 pól (w przeciwieństwie do tego, TINYINTktóry wykorzystuje jeden bajt na pole).

TINYINTma tę zaletę, że pozwala dostosować 8-wartościową maskę bitową bez martwienia się o zarządzanie kilkoma dodatkowymi kolumnami, a wyszukiwanie jest teoretycznie szybsze (pojedyncze pole liczb całkowitych w porównaniu z kilkoma polami bitowymi). Ale są pewne wady, takie jak wolniejsze porządkowanie, fantazyjne indeksowanie krzyżowe i brak nazw pól. Która dla mnie jest największą stratą; Twoja baza danych wymagałaby zewnętrznej dokumentacji, aby odnotować, które bity robią co w których maskach bitowych.

W każdym razie unikaj pokusy używania TEXTpól do przechowywania wartości logicznych lub ich zbiorów. Przeszukiwanie tekstu wymaga dużo więcej pracy dla serwera, a dowolne schematy nazewnictwa, takie jak „włącz, wyłącz, wyłącz” mogą zaszkodzić interoperacyjności.

Właśnie próbowałem grupować na bit (SQL Server 2k5) i działało dobrze. Lubię używać prawidłowego typu danych dla aplikacji. Jeśli jest to pole prawda / fałsz, używam bitu ...

Wszystkie te teoretyczne dyskusje są świetne, ale w rzeczywistości, przynajmniej jeśli używasz MySQL i naprawdę również dla SQLServer, najlepiej jest trzymać się danych niebinarnych dla swoich wartości logicznych z tego prostego powodu, że łatwiej jest z nimi pracować, gdy wyprowadzanie danych, wysyłanie zapytań i tak dalej. Jest to szczególnie ważne, jeśli próbujesz osiągnąć interoperacyjność między MySQL i SQLServer (tj. Synchronizujesz dane między nimi), ponieważ obsługa typu danych BIT jest różna w obu z nich. WIĘC w praktyce będziesz miał dużo mniej kłopotów, jeśli będziesz trzymać się numerycznego typu danych. Poleciłbym MySQL trzymać się z BOOL lub BOOLEAN, który jest przechowywany jako TINYINT (1). Nawet sposób, w jaki MySQL Workbench i MySQL Administrator wyświetlają typ danych BIT, nie jest przyjemny (to mały symbol danych binarnych).

Wydaje mi się, że nie widziałem tego wspomnianego powyżej, ale występuje problem braku możliwości agregowania kolumn BIT (np. MIN, MAX, a zwłaszcza SUM). Właśnie przetestowałem przy użyciu 2008 i problem nadal występuje. To jest największy powód, dla którego ostatnio używam tinyint - z drugiej strony lubię to, jak tinyint się skaluje - zawsze jest uciążliwe, gdy twoja flaga bitowa o wartości dwóch wartości nagle potrzebuje więcej możliwych wartości.

Wszystkie nasze tabele budujemy z polem „wektor” int. Następnie używamy tego pola jako zbioru 32 bitów, które możemy przypisać do dowolnego celu. (Potencjalnie przy użyciu grupy bitów dla zestawu stanów). Pozwala uniknąć konieczności ciągłego dodawania pól flag, jeśli zapomnimy.

@Kevin: Uważam, że można używać group byna polach bitowych (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

Wyniki:

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

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

TinyInt to moje preferencje. Następnie, wykonując zagregowane liczenia względem pola, nie musisz go rzucać. Ponadto niektóre języki frontonu interpretują Bit inaczej niż inne, a użycie TinyInt sprawia, że ​​sprawdzanie poprawności jest uniwersalne dla każdego języka interfejsu użytkownika.

Jeśli używasz MySQL, nie zaleca się używania typu danych BIT - http://www.xaprb.com/blog/2006/04/11/bit-values-in-mysql/

Lubię używać char (1) z „T” lub „F”. Tak, można go nadużywać z innymi wartościami, ale przynajmniej jest łatwy do przeglądania w raportach lub innych miejscach, w których trudniej jest pracować z wartościami bitowymi lub binarnymi.