gdzies kiedys wpadlem na taki artykul gdzie pisalo by unikac przechowywania null, gdyz zmniejszaja wydajnosc,powoduja nieczytelnosc i cos tam jeszcze. czy to prawda?

Nie, to nie prawda.

A w podręcznikach od MySQLa tak piszą, że lepiej nie używać nulli jeśli nie są potrzebne - bo nulle wymagają nie tylko dodatkowych operacji, ale i dodatkowego miejsca na przechowywanie tej specjalnej wartości. I gdzie tu prawda?

Martwicie się o wydajność jakbyście pisali potężne bazy danych. Null jest po to by go używać - unikamy dzięki temu pustych pól, które mogą spowodować zamieszanie w zapytaniach.

Na pole z NULLem baza mysql potrzebuje dodatkowego jednego bajta.
Jeśli macie pole, na które macie założoną relację i pole to może być puste, to musicie to pole dać z NULLem, gdyż inaczej nie przejdzie Wam ta relacja.
Gdy macie macie zaś pole, na które nie macie założonej relacji, a pole to jest polem liczbowym i może przyjmować liczby większe od 0 lub nic, to wówczas możecie dać je jako NOT NULL a zamiast NULL wstawiać 0. Zaoszczędzicie jeden bajt. Ja tak właśnie robię. I nie chodzi tu już o ten jeden bajt. Wydaje mi się to lepszym rozwiązaniem niż dawać NULL zamiast 0. Ale ja to robię bo wiem co robię. Gdy potrzebuję relacji, to jak najbardziej używam NULL.

Także wszystko zależy jak leży i należy używać to ze świadomością co się robi.

ps: NOT NULL też bodajże jest szybsze w indeksowaniu
ps2: i też często widziałem zalecenia by unikać NULL jeśli jest to możliwe

Jeżeli jakieś pole może przyjąć "logiczne nic", powinno to być zrealizowane przez NULL, nie przez zero, pusty ciąg czy datę 0000-00-00 00:00:00. Ewentualne różnice w szybkości działania bazy czy jej rozmiaru na dysku będą marginalne i na pewno nie będą przyczyną problemów z wydajnością.

Dobry, czytelny, jasny projekt niemal zawsze jest lepszy niż 0.02% wzrost wydajności.

PS. Domyślam się, że większość artykułów odnoszących się do unikania NULL jest napisanych na podstawie źle zaprojektowanych baz danych, gdzie 15 z 20 kolumn w wierszu ma wartość NULL.

Też kiedyś wychodziłem z założenia, że jak coś ma być nic znaczy że ma być NULL. Jednak przestawiłem się na 0 gdy NULL nie jest wymagany i nie uważam, że czytelność/przejrzystość projektu na tym cierpi.

ps: arty były pisane raczej przez fachowych ludzi i nie dotyczyły tabel z X kolumn takich czy owakich. Dotyczyły ogólnych wskazówek dotyczyczących wydajnego korzystania z mysql

To jest trochę bez sensu, bo jak się jednak patrzy na bazę danych, to jest różnica czy nie wiem na przykład: użytkownik należy do grupy o nazwie '0', czy nie należy do żadnej i wtedy co też ma mieć '0'? Wg mnie to nie jest mądrze napisane, aby unikać NULL.

Ale przecież to zależy od konkretnej sytuacji, od konkretnego projektu bazy danych! W jednej bazie użytkownik może należeć do grupy o nr 0, 1, ... albo nie należeć do żadnej, co będzie oznaczane wartością NULL. W innym projekcie może w ogóle nie istnieć grupa nr 0 i wówczas 0 może z powodzeniem oznaczać brak grupy!

Inny przykład: jak zapiszesz liczbę dzieci użytkownika? Czy jeśli nie ma on dzieci, użyjesz 0 czy NULL? Przecież 0 wystarczy, NULL tu nie jest potrzebne. Ale jeśli potrzebujesz wiedzieć, czy wiadomo, ile użytkownik posiada dzieci, to NULL może okazać się w sam raz, by taką informację zapisać: NULL to nie wiadomo ile ma dzieci, 0 - brak dzieci gdy wiadomo, że ich nie ma.

Wszystko zależy od potrzeb, od projektu. W wielu przypadkach NULL nie jest potrzebne, bo nie niesie żadnej realnej informacji i z powodzeniem może być zastąpione przez domyślną wartość typu 0, szczególnie wtedy, gdy nie potrzebujesz rozróżniać braku wartości od wartości oznaczającej "nic".

No przecież właśnie to samo napisałem wyżej ^^

Nie można narzucać haseł "Nie stosuj NULLa, to zło i kropka". Bo to nie jest prawda, na co przykładem jest to co napisałem w moim poście.

Wg. mnie jeśli potrzebujesz, to korzystasz, po coś jest stworzone.

korzystanie z wartości null powoduje wymuszone korzystanie z logiki trójwartościowej - co jest upierdliwe.
nie da się konstruować zapytań na obecność lub nieobecność danej wartości - dla prawidłowego wyniku - trzeba uwzględniać także wartości null.

z logicznego punktu widzenia wartość null, powinna być wykorzystywana jedynie w przypadku braku danej właściwości - a nie jej zerowej wartości (zero jest wartością)


przykład pierwszy, od czapy z lekka jaki mi przychodzi to tabela pojazdy, i tabela cechy pojazdu.
wpisując helikopter i samochód do tabeli pojazdy w jej cechach będziemy mieli:

pojazd_id | nazwa
1 | helikopter
2 | autobus

pojazd_id | koła | drzwi | śmigło
1 | 3 | 4 | 2
2 | 6 | 3 | null

podsumowując, wartość null, powinno się używać w przypadku, gdy opisywany obiekt nie posiada, i nie powinien posiadać danej właściwości, w każdym innym przypadku, powinno się dawać wartość domyślną.

a jak już programiści to wykorzystują - to już aż żal opisywać...
z drugiej strony, ilu programistów dobrze rozumie teorie baz danych...

j.

Tu akurat podałeś przykład w którym należy uniknąć NULLa i podać 0.

Jak dla mnie 0 to konkretna wartość - brak dzieci, a wartość NULL to brak informacji.
Przykładowo przy rejestracji tworzy się wiersz z daną osobą i kilka kolumn nieobowiązkowych - w tym liczba dzieci.

Teraz pomyślcie jak wyglądałoby by wyciąganie sumy, średniej dzieci. Jak sprawdzisz kto nie uzupełnił tej wartości (profilu)?
Ja ostatnio zacząłem doceniać korzyści NULL

"Tu akurat podałeś przykład w którym należy uniknąć NULLa i podać 0. "

Dyskusja bardzo ciekawe. Według tego co napisał autor postu o helikopterach "null używamy wtedy kiedy dana własność nigdy nie jest spełniona dla danego obiektu" Więc samochód nie ma 0 śmigieł bo 0 jest wartością, ale nie ma ich wcale czyli nie posiada wartości ( nawet 0 ) tylko NULL. Tak to rozumiem i ma to nawet sens, ale nigdy nie tworzyłem dużych baz danych, max 20-30 tabel. Przy takiej złożoności nie można mówić o problemach wydajnościowych. Przy rozglełych bazach i skomplikowanych zapytaniach może mieć znaczenie czy używamy DISTINCT czy NOT EXIST, ale optymalizacja SQL to inna sprawa.

Pozdrawiam.

EDIT:

Chociaż ja zawsze tworząc tabelę jeżeli jakaś wartość nie jest wymagana to poprostu piszę DEFAULT NULL. Może i źle, ale dowiem się z tego tematu co dalej :].

Można poczytać: http://www.bennadel.com/blog/85-Why-NULL-V...ss-Required.htm
Hasło: Null in database, how use.

no wręcz odwrotnie (chyba ze chcesz policzyć to śmigło od wentylatora..) tutaj nasz obiekt - czyli autobus nie ma takiej właściwości, i mieć nie może.



tak, jest to dobry przykład trójwarstwowej logiki.
mając 4 wpisy (ilość dzieci) programista używa nulla jako wartość domyślną zamiast 0.
user logując się - raz wpisze 0, a drugi raz zostawi pole puste (no bo skoro nie ma dzieci, to dlaczego by nie....)


w tabeli więc ląduje nam:
4
2
0
null


jaka jest średnia ilość dzieci ?
sprawdzam:: SELECT AVG(test) FROM `test`

1,5 czy 2 ?

mysql powie że 2 - co de facto jest guzik prawda, w przypadku jeśli programista zamiast '0' będzie pakował null wtedy,
wartością powinno być 1,5 ale puki nikt z księgowości nie zwróci uwagi na ten błąd - będziesz generować błędy aż miło...
taki, i temu podobne kwiatki - nieświadomie programiści generują notorycznie.


j.

Bo problem NULLa to w ogóle problem z teorią relacyjnych baz danych. W pierwszej odsłonie chyba w ogóle go nie było bo z założenia baza miała być zawsze w spójnym stanie a NULL (brak danych) ten piękny obraz zaburzał. Swego czasu świetnie opisał ten problem C. Date w "Wstępie do relacyjnych baz danych" (książka dość leciwa ale teoria chyba za bardzo się nie zmieniła). Co do wydajności to też nie byłbym taki pewien - Date wzmiankował że proste algorytmy optymalizujące SQLe działają znakomicie w relacyjnych bazach gdzie obowiązuje dwuwartościowa logika (czytaj nie ma NULLa) a są kompletnie nieprzewidywalne w wypadku logiki trójwartościowej. Tak samo jak wewnętrzne złączenia teoretycznie są mniej obciążające dla bazy niż wszelkiego typu złączenia zewnętrzne.

W praktyce - na zajęciach ze statystyki uczyli mnie że nie zostawia się w danych pustym miejsc tylko definiujemy sobie jakąś wartość dla danego typu i traktujemy ją jak brak danych. Ja tak robię też w bazach, w sumie nie wiem czy dobrze

W sumie to nigdy się nad tym nie zastanawiałem, z założenia wychodzę że jak czegoś nie ma i chcemy mieć o tym informacje to jest to NULL a nie 0 lub pusty string, Z punktu widzenia skryptu często NULL można zastąpić przez 0 i nic się nie stanie, jednak jeżeli mamy tak jak wyżej podano profil użytkownika to chcemy wiedzieć czy użytkownik nie ma dzieci czy też nie podał tej informacji tutaj już różnica jest spora.

Inny przykład, liczba komentarzy do artykułu tutaj bez różnicy możemy użyć NULL lub 0 bo wychodzi nam ta sama informacja brak komentarzy do podanego artykułu.



Tylko wówczas co za różnica ? NULL przecież z punktu widzenia bazy nie jest pusty zajmuje 1 bajt. Poza tym nie zawsze jest to możliwe, co jeżeli masz pole int i każda wartość jest poprawna czyli nie masz miejsca na 1 wartość oznaczoną jako brak danych ?

Jeżeli ktoś nie wpisze wartości to będzie rzutować na INT i da zero, nie NULL.
No jak dla mnie średnia dzieci to prawidłowo 2 - liczy tylko na pełnych danych.
A mając NULLe zawsze można dodać opcje - "Brak wartości uznaj jako zero" (nie wiem czy da radę na poziomie samej bazy, ale nawet jak nie to zawsze to zrobisz później).

Nikt nie napisał żeby unikać NULLa bo to zło i kropka. Napisano by unikać NULLa gdy naprawdę nie ma potrzeby go stosować. To drobna różnica.

1. Przede wszystkim nie dyskutujcie w oparciu o przykłady bazujące na złej strukturze bazy danych (przykład pojazdów i wspólnej tabeli do przechowywania cech samochodów i śmigłowców).
2. Takie potworki, jak AVG(col_name), gdzie do funkcji może trafić NULL również są przykładem błędnej struktury. Tym razem jest to przykład złego zapytania, które nie odrzuca rekordów z NULLem. Baza danych powinna w takim przypadku wywalić błąd (najlepiej jakby robiła to na poziomie interpretacji zapytania SQL) albo przynajmniej zwrócić NULL. Bo liczenie średniej z NULL-a przypomina liczenie sumy z puszki coli - nie ma najmniejszego sensu.
3. Jak już powiedziano, NULL powinien być zawsze traktowany jako brak informacji, czyli nie można go użyć jako wartości reprezentującej zero komentarzy danego artykułu.
4. Tak jak przypuszczałem, i tak jak widzę po przykładach w powyższej dyskusji, rady by unikać NULL-a powinny być zastąpione radami by poprawnie tworzyć strukturę bazy danych i zapytania do niej (np. skorzystanie z modelu EAV w przykładzie z cechami pojazdów).

no mi też wychodzi 2
user 1 ma czworo dzieci
user 2 ma dwoje dzieci
user 3 niema dzieci
user 4 jest cham i nie chce powiedzieć ile ma dzieci czyli niemożna go uwzględniać w statystyce

Dyskusyjne, bo interpretacja zależy od podejścia, ale można by się zgodzić, że (w powyższym przykładzie) interesuje nas liczba posiadanych dzieci do liczby userów, którzy tą informację udzielili. Ale kogoś może równie dobrze interesować zadeklarowana (czyli znana) całkowita liczba dzieci do całkowitej liczby zarejestrowanych użytkowników, i co wtedy? Po co tak? Ano np. po to, by wprowadzić nowy dział poświęcony pieluchom, gdy stosunek posiadanych dzieci/użytkowników wyniesie 1,5 lub więcej

Zastanówmy się teraz nad innym przypadkiem: załóżmy, że do każdego usera przypisana jest liczba jego kliknięć w pajacyka; ktoś kto ma bzika na punkcie NULLa, to zrobi kolumnę "liczba_klikniec" z domyślną wartością NULL, bo przecież po zarejestrowaniu user jeszcze nie ma ani jednego klika na koncie. Tymczasem to powinna być kolumna NOT NULL z domyślną wartością 0!



Bill Karwin w http://helion.pl/ksiazki/antywzorce-jezyka...rwin,antysq.htm przedstawia model EAV jako antywzorzec i odradza jego używanie.

Bo generalnie jest to złe rozwiązanie, ale jeżeli musimy wepchać nierelacyjne dane do relacyjnej bazy danych spisuje się w miarę znośnie. Na pewno lepiej niż tabela z setkami dynamicznie tworzonych kolumn z czego większość o wartości NULL.
Bezsprzecznie byłoby to złe podejście, które już chyba kilka razy potępiono w tym wątku.

@d3ut3r
Trochę spoźnione:


Ma tą pewną zaletę - NULL jest nieokreślony - a tymczasem brak danych może oznaczać wiele rzeczy -> np. konkretna wartość leży poza zakresem, nie mogła być odczytana, nie została w ogóle uzupełniona. Niby to samo ale mając coś takiego uzyskujemy dużo więcej informacji niż z samego NULLa.

PS: Co do inta to raczej mało jest takich przypadków gdy cały zakres jest poprawny i właściwy. Przynajmniej w odniesieniu do rzeczywistego świata.

Z ciekawości jakie jeszcze informacje można odczytać z dowolnej wartości oznaczonej jako brak danych ?.

to ze przykład z pojazdami jest kiepski - to fakt, chodziło o idee, a ta jak myślę jest zrozumiała.

null - tez dla ludzi. i jeśli się wie jak z tego korzystać, i z czym to się wiąże - to dlaczego by nie...
jak dla mnie jednak więcej korzyści wynika z korzystania wartości domyślnych..

w miare sensowny art.

http://blog.ksiazek.info/2011/07/10/mysql-a-null-cz-1/
http://blog.ksiazek.info/2011/07/17/mysql-a-null-cz-2/

j.

@d3ut3r
[ironia] Hm, np. że wartość to NULL [/ironia]

Brak danych to ty powinieneś uwzględnić projektując bazę. Takie pytanie - masz bazę danych na potrzeby badania medycznego w których ktoś inteligentnie postanowił oznaczyć wszystkie białe plamy jako NULL. Statystykę wyliczysz, wyniki wyliczysz. Teraz jednak ktoś podważa wyniki badania mówiąc że nie zostało przygotowane właściwie i żąda szczegółowego opisu grupy badanej, sposobu zbierania danych, kryteriów wykluczenia itd. Ty jesteś w dupie bo jedyne co masz to białe plamy z których każdy reprezentuje wszystko i nic.

W zasadzie myśle że NULL powinien się pojawić tylko jako wynik pewnych operacji na bazie (złączenia) a nigdy nie być stosowany jako element projektu. Tyle.

Trzeba umieć rozróżnić pojęcie wartości domyślnej, a wartości początkowej.
NULL tutaj zupełnie nie pasuje.

NULL - nie znasz informacji, a tutaj znasz - user zaczyna od zera kliknięć tak samo będzie np. w statystykach kampanii, liczby postów itp.

@everth
Zawsze można też zaprojektować bazę w pierwszej postaci normalnej i dane medyczne trzymać w tabelach z danymi medycznymi, a powody wykluczeń trzymać w tabeli... z powodami wykluczeń.

Ok, ale czy to nie sprowadzi się właściwie do tego co miałem na myśli? Czyli każdy potencjalny brak danych oznaczamy kodem wskazującym na jego naturę? To gdzie trzymamy definicje to chyba sprawa drugorzędna. Albo masz na myśli zupełnie coś innego a ja nie rozumiem

@everth:

Chodziło raczej o to, że podany przez Ciebie przykład stawia NULL-a w złym świetle nie dlatego, że NULL sam w sobie jest zły. Podałeś przykład źle zaprojektowanej/używanej bazy danych jako argument przeciwko NULL-owi.

Powinieneś albo uwzględnić istnienie NULL-a przy generowaniu statystyk (tak, by nie fałszował on ich wyniku) albo informacje o każdej "białej plamie" trzymać w osobnej tabeli.

Powinno się zawsze używać NULL (ale nie string null co nieraz widziałem) jeśli nie mamy domyślnie lepszej wartości (typu liczba kliknięć = 0) - czyli zapchajdziurą ma być null a nie zero czy pusty string. Bo wtedy unikamy problemów z filtrowaniem, zliczaniem czy złączaniem, domyślnie zakładane pole ma null i nie musimy tego zmieniać czy wysyłać do bazy pustego stringa czy zero. Po to jest null żeby z niego korzystać, wszystkie programy do obsługi baz danych z których korzystałem uwzględniały null. Null to jest null, od razu widać, że to coś wyczesanego bo każdy program to pogrubia, koloruje etc. Każdy rozsądnie napisany kod rozumie null, bo przekazuje się/zwraca true, false albo właśnie null

@Crozin
Masz rację. Tylko nie wiem jak ta osobna tabela miałaby wyglądać gdyby miała opisywać charakter braków powiedzmy z kilkuset kolumn z kilkunastu tabel i czy w ogóle później używanie czegoś takiego byłoby praktyczne.

@Pilsener
Ja tam uważam że NULLem może być cokolwiek na co się umówimy. Trzeba tylko pamiętać o tym przy operowaniu na danych. Jeśli np. umówimy się że dla danej kolumny brak danych to -1 a później przeprowadzimy inkrementację na wszystkich wierszach bez warunku to mamy problem. Nie operowałem na innych bazach niż MySQL czy SQLite ale czytałem że te bardziej zaawansowane jak postgres czy oracle pozwalają na definiowanie własnych typów w schematach. Takie coś pasowało by tutaj idealnie.

Dodatkowo jeśli ty decydujesz się na użycie innego typu (albo i umówionej wartości) niż typ NULL to masz ten luksus że wiesz które braki danych zostały wprowadzone świadomie przez ciebie a które są wynikiem np. nieprawidłowego zapytania albo wynikiem jakiejś nieprzewidzianej operacji.


Ale ja nie jestem pewien czy te same funkcje między różnymi bazami danych tak samo zachowują się wobec NULLa. Coś mi mówi że nie, choć mogę się mylić.