Czy istnieją powody, dla których nie zapisujemy wartości logicznych w SQL jako typy danych bitowych bez NULL? Widzę je często przechowywane jako liczby całkowite bez ograniczeń do wartości granicznych do 0 i 1, oraz jako ciągi z takimi elementami jak T/F, True/False, tak/nie itd., Znowu bez ograniczeń. Czy nie lepiej jest przechowywać je jako bity i nie trzeba się martwić o dodatkowe ograniczenia? Czego tu mi brakuje?Czy istnieją powody, aby nie przechowywać wartości logicznych w SQL jako typy danych bitowych?
Odpowiedz
będę zawsze trzymać się z najmniejszym typem danych mogę zapisać to.
- SQLServer: BIT
- Oracle: Number (1) (lub BOOLEAN w PL/SQL)
- MySQL: TINYINT (IIRC BOOLEAN mapy do tego automatycznie)
Edit: Boolean Oracle to tylko PL/SQL, a nie definicja tabeli. Zaktualizowana odpowiedź odzwierciedla to.
Jednym z powodów jest to, że ludzie nie wiedzą o bitach lub myślą, że y/n jest prostszy w formatowaniu. Innym powodem jest to, że czasami myślisz: hmm może z czasem będzie to coś więcej niż pole bool. i robisz to na wszelki wypadek.
nie brakuje niczego :)
co zwykle dzieje się w dół drogi jest to, że ktoś chce dodać również może się tak i nie, jeśli masz trochę to teraz trzeba zmienić cały swój kod do TINYINT
jeśli miał tinyint, aby rozpocząć z wtedy nie ... wierzysz mi, że dzieje się to bardziej, niż myślisz
Kiedy chcę mieć booleany w bazie danych zawsze używam typu danych bitowych. W SQL mogą być NULL. Ale podczas uruchamiania twojego programu musisz wziąć pod uwagę, że bool (np. W C#) jest typem wartości, który w tym przypadku nie może mieć wartości NULL. Musisz porównać z wartością System.DBNull.
Nie możesz po prostu określić zmiennej jako Nullable
sprawiają, że NOT NULL w SQL ....... utworzyć tabelę bla (bit answer not null) – SQLMenace
Problem jest to, co obsługuje ADO.NET lub inne ramy dostępu do danych. jeśli pozwala na Nullable
Zawsze przechowujemy dane jako małe, są małe i, co ważniejsze, w takim przypadku są przeznaczone.
Mieliśmy czasy, w których użytkownik końcowy miał pracować z danymi bezpośrednio, a do nich, Tak/Nie lub T/N było bardziej czytelne. W tym przypadku właśnie utworzyliśmy widok odzwierciedlający bardziej przyjazny wyświetlacz danych.
Moje ostatnie 2 prace po tym, jak oddałem swój pierwszy projekt, sprawiły, że wróciłem i zmieniłem wszystkie 0 na "N", a 1 na "T" Oba miały dokładnie taki sam powód. "Nigdy nie możemy sobie przypomnieć, która jest która" Myślałem, że 0 = fałsz obliczył 101, ale najwyraźniej często nie można o tym wiedzieć. A może to znak, że nie wybieram dobrych miejsc do pracy. – dwidel
widzę je często przechowywane jako liczby całkowite bez ograniczeń do wartości dopuszczalnych dla 0 i 1, a jako ciągi rzeczy jak T/F, prawda/fałsz, tak/nie, itp, ponownie bez ograniczenia. Czy nie lepiej jest przechowywać je jako bity, a nie trzeba się martwić o dodatkowe ograniczenia ?
Tak!
Czego mi tu brakuje?
Właściwie powinno to być "czego NIE JESTEM tutaj?" a odpowiedź brzmi: zdrowy rozsądek.
BIT to typ danych zwykle używany do przechowywania wartości BOOLEAN. Po prostu dlatego, że jeśli BIT wynosi 1, to jest to prawda, a 0 to fałsz. To takie proste.
Myślę, że trzecia forma normalizacyjna stwierdziłaby, że powinieneś mieć tabelę, która przechowuje wartości True i False, i odwołać się do tego. Upewnij się, że robisz to również ze swoimi datami!
Ale kto całkowicie przylega do 3NF? ;)
Być może zechcesz znaleźć inne źródło swojej definicji trzeciej postaci normalnej. Nic nie stwierdza, że wszystkie wartości we wszystkich kolumnach muszą być również gdzieś przechowywane w tabelach. –
Używam trochę. Ale czasami chcę być w stanie mieć możliwość zwrócenia false - lub wiele wartości true (jak komunikaty o błędach). Więc jeśli użyję int zamiast boolean, mogę zrobić coś takiego:
0 = False 1 = Nieprawidłowe hasło 2 = Nazwa użytkownika nie istnieje. 3 = Konto zablokowane - dla wielu nieudanych prób. 4 = Konto wyłączone.
I tak dalej.
To nie jest boolean. Jest to wartość kodu. Wartość logiczna z definicji to prawda lub fałsz, a nie ma wielu definicji wartości true. –
Jak powiedziałem, bardzo często używam. Następnie podałem alternatywne rozwiązanie. I jeśli czytasz mój post mówiłem czasami, że używam int zamiast boolean. –
Kilka powodów, aby nie zrobić tak, to:
Nie wszystkie bazy danych mają bitowego typu danych więc użyć int zamiast aby móc używać differnt backendów
W niektórych bazach danych nie można Indeks polem bitowym.
I często to, co masz, nie jest naprawdę prawdziwe/fałszywe, tak/nie, bez innych możliwości. Na przykład możesz mieć pole bitowe dla statusu oznaczające coś otwartego lub zamkniętego. Ale później zdajesz sobie sprawę, że musisz anulować także status.
Użyj funkcji wyliczenia, jeśli masz więcej niż dwa stany.
Re. "najmniejszy dostępny typ danych": wartości BIT programu SQL Server nie są w rzeczywistości jednobitowe, ale wielokrotnością pełnej bajty. Jednak więcej niż jeden BIT w tej samej tabeli jest zwinięty do tego samego magazynu. – Tomalak
MySQL obsługuje również typ BIT, a jego wymagania dotyczące przechowywania działają dokładnie tak, jak wyjaśnił Tomalak. –
@Chad: kolumny BIT MySQL są wyraźnie różne od kolumn BIT SQLServer; pole BIT SQLServer przechowuje tylko jedną wartość, a pola BIT są łączone razem, gdy są przechowywane, jeśli jest ich więcej niż jeden. Pole BIT MySQL jest maską bitową z 1 do 64 bitów (na podstawie deklaracji). – Powerlord