Brak wartości - NULL czy puste pole

0

Witam.

Projektuję system internetowy i przy proj. bazy danych MySQL natknąłem się na ten problem:

W tabelach będzie istniało wiele pól nieobowiązkowych z punktu widzenia aplikacji. Zastanawiam się nad wyborem pomiędzy NULL a NOT NULL, gdyż:

  • nie wiem co zajmuje mniej miejsca w bazie: wartość null czy puste pole
  • nie wiem która opcja będzie szybsza pod kątem wyszukiwania, indeksowania kolumny w bazie, jeśli będzie dużo wystąpień "nieobowiązkowych" pól

Pomożecie?

1

jak pole jest nieobowiazkowe to daj null a nie jakies magiczne wartosci.
staraj sie odzwierciedlic w bazie rzeczywistosc, zapewnic normalizacje a takimi rzeczami jak zajetosc miejsca w bazie, predkosc wyszukiwania czy indeksowania nulli to serio sie nie zajmuj. nigdy nie byly i nie beda to powazne problemy dotyczace uzytkownika baz danych.

0

Spodziewałem się idiotycznego komentarza (w tym przypadku somekind).

Naprawdę nie ma to znaczenia? Przecież null to nie to samo co '' (dwa apostrofy) ani 0.

0

@Webowiec, zła wiadomość dla większości RDBMS '' jest równe null i trzeba się pałować by wybierać puste ciągi znaków. W praktyce → nieobowiązkowe === null. To co może być przydatne to odpowiednie użycie widoków i aliasów tak by uprościć sobie model.

0
Webowiec napisał(a):

Spodziewałem się idiotycznego komentarza (w tym przypadku somekind).

Naprawdę nie ma to znaczenia? Przecież null to nie to samo co '' (dwa apostrofy) ani 0.

Oczywiście, że to ma znaczenie, bo NULL i pusty string to DWIE wartości. Problem w tym, że twórcy MySQL mają na ten temat inne zdanie.
Nie wiem tylko, co jest idiotyczne - ich decyzja, czy Twoje niezrozumienie dla mojego komentarza.

1

@somekind
Ja tam się nie znam, ale manual mówi co innego: http://dev.mysql.com/doc/refman/5.7/en/problems-with-null.html

@Webowiec
tl;dr Wg stacka unikaj nulla kiedy to tylko możliwe.
http://stackoverflow.com/questions/1106258/mysql-null-vs

0

Według stackoverflow, nie zaleca się używania NULLA chociażby z uwagi na to że (na przykład) operacja połączenia dwóch ciągów, przy czym jeden z nich jest nullem, zawsze daje NULL, a nie tego możemy oczekiwać.

Jednak w kwestii, która mnie również interesuje, null wygrywa z pustą wartością pod względem prędkości wyszukiwania (określone wg stacka jako "nieco szybciej").

Wniosek jest taki, że tu nie ma ekspertów :-)

0
Webowiec napisał(a):

nie zaleca się używania NULLA chociażby z uwagi na to że (na przykład) operacja połączenia dwóch ciągów, przy czym jeden z nich jest nullem, zawsze daje NULL, a nie tego możemy oczekiwać.
niby czemu nie tego mozemy oczekiwac, akurat wyniki dzialan operacji z nullem w bazach danych jest imo calkiem intuicyjny. jesli dobrze modelujesz dane (zamiast kombinowac z mikrooptymalizacjami na poczatku ;)) to chyba lepiej ze jak laczysz cos okreslonego z czyms nieokreslonym to wynik jest nieokreslony, nie? poza tym zawsze masz COALESCE, NVL, IFNULL itp.

Webowiec napisał(a):

Jednak w kwestii, która mnie również interesuje, null wygrywa z pustą wartością pod względem prędkości wyszukiwania (określone wg stacka jako "nieco szybciej").
taaa, nieco szybciej to satysfakcjonujaca, merytoryczna odpowiedz ;) czyli co, 15KB na TB danych? 2 sekundy na 15 minutowym query? :)

0
Webowiec napisał(a):

Według stackoverflow, nie zaleca się używania NULLA chociażby z uwagi na to że (na przykład) operacja połączenia dwóch ciągów, przy czym jeden z nich jest nullem, zawsze daje NULL, a nie tego możemy oczekiwać.

Głupszego uzasadnienia jak żyję nie widziałem.
Mogli jeszcze uzasadnić tym, że

='' 

pisze się szybciej niż IS NULL

1 użytkowników online, w tym zalogowanych: 0, gości: 1