SQL: pusty ciąg vs NULL

72

Wiem, że ten temat jest nieco kontrowersyjny i po Internecie płynie wiele różnych artykułów / opinii. Niestety większość z nich zakłada, że ​​osoba nie wie, jaka jest różnica między NULL a pustym ciągiem. Opowiadają więc historie o zaskakujących wynikach z łączeniami / agregacjami i generalnie robią nieco bardziej zaawansowane lekcje SQL. Robiąc to, absolutnie nie rozumieją sedna i dlatego są dla mnie bezużyteczne. Mam nadzieję, że to pytanie i wszystkie odpowiedzi posuną temat nieco do przodu.

Załóżmy, że mam tabelę z danymi osobowymi (imię i nazwisko, urodzenie itp.), W której jedną z kolumn jest adres e-mail z typem varchar. Zakładamy, że z jakiegoś powodu niektóre osoby mogą nie chcieć podać adresu e-mail. Podczas wstawiania takich danych (bez wiadomości e-mail) do tabeli dostępne są dwie opcje: ustaw komórkę na NULL lub ustaw pusty ciąg (''). Załóżmy, że znam wszystkie techniczne implikacje wyboru jednego rozwiązania zamiast drugiego i mogę utworzyć poprawne zapytania SQL dla każdego scenariusza. Problem występuje nawet wtedy, gdy obie wartości różnią się na poziomie technicznym, są dokładnie takie same na poziomie logicznym. Po spojrzeniu na NULL i „” doszedłem do jednego wniosku: nie znam adresu e-mail faceta. Nie ważne jak bardzo się starałem, Nie mogłem wysłać wiadomości e-mail przy użyciu wartości NULL lub pustego ciągu, więc najwyraźniej większość serwerów SMTP zgadza się z moją logiką. Więc zwykle używam NULL, gdy nie znam wartości i uważam pusty ciąg za złą rzecz.

Po kilku intensywnych rozmowach z kolegami zadałem dwa pytania:

  1. czy mam rację, zakładając, że użycie pustego łańcucha dla nieznanej wartości powoduje, że baza danych „kłamie” na temat faktów? Mówiąc ściślej: korzystając z idei SQL, co jest wartością, a co nie, mogę dojść do wniosku: mamy adres e-mail, po prostu odkrywając, że nie jest on zerowy. Ale później, próbując wysłać e-mail, dochodzę do sprzecznego wniosku: nie, nie mamy adresu e-mail, że @! # $ Baza danych musiała kłamać!

  2. Czy istnieje logiczny scenariusz, w którym pusty ciąg „” mógłby być tak dobrym nośnikiem ważnych informacji (oprócz wartości i bez wartości), co byłoby kłopotliwe / nieefektywne do przechowywania w jakikolwiek inny sposób (np. Dodatkowa kolumna). Widziałem wiele postów stwierdzających, że czasami warto używać pustych ciągów wraz z rzeczywistymi wartościami i wartościami NULL, ale jak dotąd nie widziałem scenariusza, który byłby logiczny (pod względem projektu SQL / DB).

PS Niektórzy ludzie będą mieli ochotę odpowiedzieć, że to kwestia osobistego gustu. Nie zgadzam się Dla mnie jest to decyzja projektowa z ważnymi konsekwencjami. Chciałbym więc zobaczyć odpowiedzi, w których opozycja na ten temat jest poparta logicznymi i / lub technicznymi przyczynami.

Jacek Prucia
źródło
11
Czy wiesz, że w Oracle pusty ciąg ma wartość NULL?
user281377,
8
@ammoQ: Traktowanie przez Oracle ciągów zerowej długości jest niestandardowe. Poza tym, ''nawet w Oracle, to nie to samo co NULL. Na przykład przypisanie CHAR(1)kolumny wartości ''spowoduje ' '(tj. Spację), a nie NULL. Poza tym, gdyby Jacek używał Oracle, to pytanie prawdopodobnie nawet nie pojawiłoby się :-)
Dean Harding
2
Dziekan: Masz rację co do przykładu char (1), ale to kolejny WTF, ponieważ '' IS NULLewaluuje truew PL / SQL.
user281377,
„czy mam rację, zakładając, że użycie pustego łańcucha dla nieznanej wartości powoduje, że baza danych„ kłamie ”na temat faktów?” jeśli twoi użytkownicy biznesowi nie dbają o to, co nieznane czy puste, czy kłamstwo w ogóle ma znaczenie?
Andy
Jeśli musisz przejść przez ciąg znaków ... proszę, upewnij się, że jest pusty. Ze względu na wszystkich programistów nie pozwól, aby ciąg znaków ze spacją reprezentował twoją nieznaną wartość. Błagam Cię.
Airn5475,

Odpowiedzi:

83

Powiedziałbym, że NULLjest to właściwy wybór dla „brak adresu e-mail”. Istnieje wiele „nieprawidłowych” adresów e-mail, a „” (pusty ciąg) to tylko jeden. Na przykład „foo” nie jest prawidłowym adresem e-mail, „a @ b @ c” jest nieprawidłowe i tak dalej. Dlatego, że „” nie jest prawidłowym adresem e-mail, nie ma powodu, aby używać go jako wartości „brak adresu e-mail”.

Myślę, że masz rację mówiąc, że „” nie jest poprawnym sposobem powiedzenia „Nie mam wartości dla tej kolumny”. „” to wartość.

Przykładem tego, gdzie „” może być prawidłową wartością, oddzielne od NULLmoże być drugie imię osoby. Nie każdy ma drugie imię, więc musisz odróżnić „brak drugiego imienia” („” - pusty ciąg znaków) od „Nie wiem, czy ta osoba ma drugie imię, czy nie” ( NULL). Prawdopodobnie istnieje wiele innych przykładów, w których pusty ciąg jest nadal prawidłową wartością dla kolumny.

Dean Harding
źródło
5
Kompletnie się zgadzam. NULL jest tam z jakiegoś powodu. WYBIERZ LICZBĘ (*) OD TWOJEGO TELEFONU, GDZIE JEST E-MAIL [NIE] NULL to sposób, aby to zrobić, a nie porównywanie ciągów, które zwykle będzie wolniejsze (nawet w przypadku pustych ciągów, ale nie jestem tego pewien :).
LudoMC,
5
Myślę, że NULLnie oznacza to, że nie ma adresu e-mail, myślę, że oznacza to, że adres e-mail nie jest obecnie znany, nie istnieje lub nie można go wypełnić z innych powodów. Na szczęście prawdopodobnie nie ma sytuacji, w której ktoś chciałby przechowywać w bazie danych informacje o ludziach, którzy naprawdę nie mają i nie planują posiadania adresu e-mail, w przeciwnym razie prawdopodobnie konieczne byłoby oddzielne pole logiczne.
Alexey,
9
@Alexey - NULL oznacza brak wartości. Jak zauważyli inni, pusty ciąg znaków jest wartością.
Ramhound,
3
@Ramhound, zgadzam się, że pusty ciąg jest wartością i że NULL niejasno oznacza „nie ma wartości”. Właśnie wyjaśniłem moją interpretację „bez wartości”. Moim zdaniem to nie to samo, co „osoba nie otworzyła żadnego konta e-mail”. Jest to raczej „brak zarejestrowanego adresu e-mail dla tej osoby”.
Alexey,
5
@Ramhound NULL oznacza, że ​​nie ma wartości. Osoba bez drugiego imienia nie ma tam żadnej wartości. Dlatego NULL powinien być również użyty w środkowej kolumnie początkowej ... Co jest całkowicie przeciwne argumentowi przedstawionemu w tej odpowiedzi.
Izkata,
41

Zgadzając się z powyższymi komentarzami, chciałbym dodać ten argument jako główną motywację:

  1. Dla każdego programisty przeglądającego bazę danych oczywiste jest, że pole oznaczone jako NULL jest polem opcjonalnym. (tzn. rekord nie wymaga danych dla tej kolumny)
  2. Jeśli zaznaczysz pole NIE NULL, każdy programista powinien intuicyjnie założyć, że jest to pole Wymagane.
  3. W polu, które zezwala na wartości zerowe, programiści powinni oczekiwać wartości zerowych niż pustych ciągów.

Ze względu na samodokumentujące intuicyjne kodowanie należy użyć NULL zamiast pustych ciągów.

colinbashbash
źródło
4
+1 To jest argument „najmniejszego zdziwienia” w odniesieniu do programistów przeciwko pustym ciągom znaków. Żaden programista, który pojawi się później, nie spodziewałby się, że puste ciągi będą reprezentować „brak adresu e-mail”.
Thomas
6

W twoim przykładzie, jeśli jest to wartość bezpośrednio z pola internetowego - użyłbym pustego ciągu. Jeśli użytkownik może określić, że nie chce podawać wiadomości e-mail, lub może ją usunąć - to NULL.

Oto link do punktów, które możesz wziąć pod uwagę: https://stackoverflow.com/questions/405909/null-vs-empty-when-dealing-with-user-input/405945#405945

--- edytowane (w odpowiedzi na komentarz Thomasa) ---

Bazy danych nie działają bez aplikacji, które ich używają. Definiowanie wartości NULL lub „” nie ma wartości, jeśli aplikacja nie może jej poprawnie użyć.

Rozważ jeden przykład, w którym użytkownik wypełnia DŁUGI formularz i naciśnij Enter, który wyśle ​​żądanie trwałego do serwera. Mógł być w trakcie wprowadzania swojego adresu e-mail. Najprawdopodobniej chcesz przechowywać wszystko, co ma w polu e-mail, aby później mógł to zakończyć. Co jeśli wprowadzi tylko jedną postać? Co jeśli wprowadzi jeden znak, a następnie go usunie? Gdy wiadomość e-mail nie jest wymagana, czasami użytkownicy chcą ją usunąć: najłatwiejszy sposób na wyczyszczenie pola. Również w przypadku, gdy wiadomość e-mail nie jest wymagana, warto ją zweryfikować przed wysłaniem.

Kolejny przykład: użytkownik podaje wiadomość e-mail jako spamto @ [duża firma] .com - w takim przypadku nie ma potrzeby wysyłania wiadomości e-mail, nawet jeśli istnieje ona i jest ważna (a może nawet istnieć). Wysyłanie jednego takiego może być tanie, ale jeśli jest 10 000 użytkowników z takimi e-mailami do codziennych subskrypcji, taka weryfikacja może zaoszczędzić dużo czasu.

Konstantin Petrukhnov
źródło
7
-1. Nie ma znaczenia, czy baza danych prowadzi witrynę, czy nie. Projektowanie baz danych to inny świat niż projektowanie stron internetowych. Baza danych powinna być zaprojektowana tak, aby przechwytywać fakty dotyczące domeny biznesowej niezależnie od interfejsu używanego do pisania do niej. Według twojej logiki, czy powinieneś używać zer, jeśli przypadkowo pierwsza aplikacja jest wykonywalna? Co się stanie, jeśli pierwsza aplikacja to aplikacja internetowa, a następna aplikacja to aplikacja mobilna? Zaprojektuj bazę danych do przechwytywania faktów przy użyciu reguł normalizacji i zaprojektuj stronę internetową do pisania.
Thomas
Cieszę się, że nauczyłeś się pisać i komentować tę stronę :) Nadal uważam, że DB powinna obsługiwać aplikację, która z niej korzysta. Sprawdź moją zredagowaną odpowiedź.
Konstantin Petrukhnov,
4
Bazy danych nie działają bez aplikacji, które ich używają. Z mojego doświadczenia wynika, że ​​jest to po prostu nieprawda i krótkowzroczność. Prawie zawsze baza danych jest wykorzystywana poza aplikacją, dla której została zaprojektowana. Zasadniczo bazy danych przetrwają dłużej niż aplikacje, dla których zostały zbudowane. Bazy danych powinny być zaprojektowane do zbierania faktów na temat firmy, a interfejs użytkownika powinien być zbudowany do odczytu i zapisu w bazie danych, a nie na odwrót. Projektowanie relacji jest zupełnie innym sposobem myślenia niż projektowanie aplikacji.
Thomas,
2
Przykłady, w których baza danych nie jest używana wyłącznie przez oryginalną aplikację: raporty, integracje z innymi systemami.
Thomas,
1
Jak wskazał Thomas, bazy danych mogą i często są używane przez więcej niż jedną aplikację, co zwiększa wagę idei utrzymania danych DB w czystości. Jeśli nie chcesz / nie możesz obsługiwać wartości NULL w swojej aplikacji, możesz po prostu zastąpić je „magicznymi wartościami” (ładny opis Thomas) w warstwie dostępu do danych. W ten sposób wszelkie przyszłe aplikacje, które chcą uzyskać dostęp do bazy danych, nie muszą wiedzieć o magicznych wartościach oryginalnych aplikacji / ich zgodności.
zgina
5

Myślę, że odpowiedź Dean Hardings naprawdę ładnie to obejmuje. To powiedziawszy, chciałbym wspomnieć, że mówiąc o wartościach NULL vs pustych ciągach na poziomie DB, powinieneś pomyśleć o innych typach danych. Czy zapisałbyś datę minimalną, gdy nie podano daty? lub -1, gdy nie podano int? Przechowywanie wartości, gdy nie masz żadnej wartości, oznacza, że ​​musisz śledzić cały zakres wartości innych. Co najmniej jeden dla każdego typu danych (być może więcej, gdy dostaniesz przypadki, w których -1 jest wartością rzeczywistą, więc musisz mieć jakieś alternatywne itp.). Jeśli potrzebujesz / chcesz zrobić coś „zbędnego” na poziomie aplikacji, to jedno, ale nie ma potrzeby zanieczyszczania twoich danych.

zgięcia
źródło
2
+1 - To właśnie nazywam „Magicznym rozwiązaniem”. Musimy opracować magiczną wartość dla każdego typu danych, aby reprezentować brak wartości. Ponadto w niektórych kolumnach wspólna wartość magiczna jest lub staje się uzasadnioną wartością, a zatem potrzebna jest nowa wartość magiczna.
Thomas
5

Niestety Oracle pomyliło reprezentację ciągu VARCHAR o długości zero z reprezentacją NULL. Oba są wewnętrznie reprezentowane przez jeden bajt o wartości zero. To sprawia, że ​​dyskusja jest o wiele trudniejsza.

Wiele zamieszania wokół NULL koncentruje się wokół logiki trójwartościowej . Rozważ następujący pseudokod:

if ZIPCODE = NULL
    print "ZIPCODE is NULL"
else if ZIPCODE <> NULL
    print "ZIPCODE is not NULL"
else print "Something unknown has happened"

Nie spodziewałbyś się trzeciej wiadomości, ale to byś otrzymał, pod logiką o trzech wartościach. Trzy ceniona logika prowadzi ludzi do licznych błędów.

Innym źródłem zamieszania jest wyciąganie wniosków z braku danych, takich jak wyciąganie wniosków z psa, który nie szczekał w nocy. Często te wnioski nie były tym, co zamierzał napisać NULL.

To powiedziawszy, istnieje wiele sytuacji, w których NULL dobrze radzi sobie z brakiem danych i daje dokładnie pożądane wyniki. Jednym z przykładów są klucze obce w relacjach opcjonalnych. Jeśli użyjesz NULL, aby wskazać brak relacji w danym wierszu, wiersz ten wypadnie z połączenia wewnętrznego, tak jak można się spodziewać.

Pamiętaj również, że nawet jeśli całkowicie unikniesz NULLS w przechowywanych danych (szósta postać normalna), jeśli wykonasz jakiekolwiek zewnętrzne sprzężenia, nadal będziesz musiał poradzić sobie z NULLS.

Walter Mitty
źródło
4

Użyj Null.

Nie ma sensu przechowywanie wartości „”, gdy wystarczy zrobić pole w tabeli, które ma wartość null. Sprawia to, że zapytania są bardziej oczywiste.

Które zapytanie SQL jest bardziej oczywiste i czytelne, jeśli chcesz znaleźć użytkowników z adresem e-mail?

  1. SELECT * FROM Users WHERE email_address != ''

  2. SELECT * FROM Users WHERE email_address IS NOT NULL

  3. SELECT * FROM Users WHERE email_address != '' and email_address IS NOT NULL

Powiedziałbym, że 2 to. Chociaż 3 jest bardziej niezawodny w przypadkach, w których przechowywane są złe dane.

W przypadku adresu e-mail w formularzu, który jest opcjonalny, należy go również uwzględnić w tabeli. W SQL jest to pole zerowalne, co oznacza, że ​​nie jest znane.

Nie mogę wymyślić żadnej rozsądnej wartości biznesowej w przechowywaniu pustego łańcucha w tabeli innej niż po prostu zły projekt. To tak, jakby przechowywać wartość ciągu „NULL” lub „PUSTE”, a programiści zakładają , że jest to ciąg zerowy lub pusty. Dla mnie to zły projekt. Po co przechowywać to, gdy jest NULL?

Po prostu użyj NULL, a sprawisz, że wszyscy będą trochę bardziej szczęśliwi.

WIĘCEJ INFORMACJI:

SQL korzysta z trójwartościowego systemu logicznego: True, False i Unknown.

Aby uzyskać lepsze i bardziej szczegółowe wyjaśnienie, polecam programistom przeczytanie: Kwerendy SQL - poza PRAWDĄ i FAŁSZ .

gąbka
źródło
3

w przypadku konkretnego pytania technicznego problem nie jest równy null vs pusty ciąg, jest to błąd sprawdzania poprawności . Pusty ciąg nie jest prawidłowym adresem e-mail!

w przypadku pytania filozoficznego odpowiedź jest podobna: zweryfikuj swoje dane wejściowe. Jeśli pusty ciąg jest poprawną wartością dla danego pola, należy się spodziewać i kod dla niego; jeśli nie, użyj null.

Pusty ciąg znaków byłby ważnym wkładem do odpowiedzi na pytanie: Co mim powiedział żyrafie?

Steven A. Lowe
źródło
Nawet przy najlepszych intencjach na świecie walidacja może nie rozwiązać tego problemu - być może nadal będzie musiał zastosować metodę dotyczącą wierszy, w których wszystkie kolumny muszą mieć jakąś wartość. W takim przypadku pozostaje pytanie - jakiej wartości użyć, gdy nie ma wartości? Odpowiedzią będzie oczywiście: wartość, która nie wskazuje żadnej wartości. W bazach danych jest to zwykle NULL.
jmoreno
2

Mógłbym wymyślić przyczynę posiadania wartości NULL i pustego ciągu:

  • Masz poprawny adres e-mail: [email protected]
  • Nie masz (i prawdopodobnie powinieneś poprosić o jeden): NULL
  • Wiesz, że ta osoba nie ma adresu e-mail: Empty String.

Jednak nie zaleciłbym tego i użyj osobnego pola, aby zapytać, czy wiesz, że żadne nie istnieje.

Marcel
źródło
1

Pytanie, jakie rozumiem, brzmi, które interpretacje NULL i pusty ciąg powinny zostać wybrane. Zależy to od tego, w ilu stanach może znajdować się dane pole.

Interpretacja zależy od sposobu dostępu do bazy danych. Jeśli w kodzie jest warstwa, która całkowicie wyodrębnia bazę danych, to wybór jakiejkolwiek polityki (w tym dwu-coulmn), która działa, jest całkowicie akceptowalny. (Jasne dokumentowanie zasad jest jednak ważne). Jeśli jednak dostęp do bazy danych jest uzyskiwany w kilku miejscach, powinieneś użyć bardzo prostego schematu, ponieważ kod będzie trudniejszy w utrzymaniu i może być w tym przypadku błędny.

apoorv020
źródło
1

Zasadniczo na poziomie logicznym nie ma różnicy między „nieprawidłową” wartością a „brakiem wprowadzania danych przez użytkownika”, są to po prostu wszystkie „przypadki szczególne” przez większość czasu. Przypadek błędu.

Posiadanie null zajmuje dodatkowe miejsce: ceil (columns_with_null / 8) w bajtach / na wiersz.

Pusta komórka i null są sposobem na oznaczenie, że coś jest nie tak / powinno być domyślne. Dlaczego potrzebujesz 2 „złych” stanów? Po co używać wartości NULL, jeśli zajmują dodatkowe miejsce i oznaczają dokładnie to samo, co puste ciągi znaków? To po prostu wprowadzi zamieszanie i nadmiarowość, gdy masz dwie rzeczy, które oznaczają (to może oznaczać) dokładnie to samo, łatwo zapomnieć, że powinieneś używać NULL zamiast pustych ciągów (jeśli np. Użytkownik pominął niektóre pola).

Twoje dane mogą stać się bałaganem. W idealnym świecie powiedziałbyś, że „dane będą zawsze poprawne, a ja zapamiętam” ... ale kiedy ludzie muszą pracować w zespole i nie wszyscy są dokładnie na twoim poziomie, nierzadko można zobaczyć GDZIE (aa. xx <> '' ORAZ bb.zz NIE JEST NULL)

Zamiast więc poprawiać członków mojego zespołu co drugi dzień, po prostu egzekwuję prostą zasadę. Brak wartości zerowych, NIGDY!

Liczenie wartości NON-NULL jest szybsze ... proste pytanie, po co byś to zrobił?

Sławek
źródło
Pamiętam gdzieś, że użycie NULL jest w rzeczywistości kosztem (zarówno pod względem obliczeń, jak i przechowywania) bazy danych. Warto więc wprowadzić tę formułę.
Jacek Prucia
Nie zapominaj, że VARCHARkolumna zajmie co najmniej 1 bajt, aby zapisać długość łańcucha, nawet jeśli wynosi zero.
dan04
Pusta komórka i null są sposobem na oznaczenie, że coś jest nie tak . Nie prawda. Wartość null jest sposobem wskazania braku wartości. Założę się, że większość RDBMS używa tablicy bitów w każdym wierszu, aby wskazać, które kolumny są puste. Zatem dodatkowa przestrzeń jest tak mała, że ​​nie ma znaczenia. Martwienie się o dodatkowe przetwarzanie jest przedwczesną optymalizacją i nie będzie niczym w porównaniu z ograniczeniami prędkości stworzonymi dla innych programistów, aby „odkryć”, że celowo użyłeś pustych ciągów.
Thomas
3
Brak wartości null . To jest podejście strusia. „Wsadzimy głowę w piasek i stwierdzimy, że nie ma nieobecnych wartości”. Zwykle prowadzi to do rozwiązania magicznej wartości, w którym trzeba wymyślić magiczną wartość dla każdego typu danych, która reprezentuje brak wartości.
Thomas
1

Zwykle patrzę na to nie z perspektywy DB, ale z perspektywy programu. Wiem, że to pytanie dotyczy kliknięcia SQL, ale tak naprawdę, ilu użytkowników ma bezpośredni dostęp do danych?

W programie nie lubię null / nothing. Jest kilka wyjątków, ale one są po prostu takie. A te wyjątki są naprawdę po prostu złymi implementacjami.

Jeśli więc użytkownik nie podał adresu e-mail, powinno być coś, co określa, czy jest to poprawne, czy nie. Jeśli pusty e-mail jest w porządku, wyświetla pusty ciąg. Jeśli użytkownik nie podał wiadomości e-mail, co narusza regułę, obiekt powinien to zaznaczyć.

Idea zerowego znaczenia ma charakter starej szkoły i jest czymś, nad czym muszą pracować nowi programiści.

Nawet w projekcie DB, dlaczego pole e-mail nie pozwala na wartości zerowe i ma ciąg o zerowej długości oraz inne pole wskazujące, czy użytkownik coś wprowadził? Czy można zapytać o DBMS o tyle? Moim zdaniem DB nie powinien obsługiwać ani logiki biznesowej, ani logiki wyświetlania. Nie został stworzony do tego, a zatem bardzo źle sobie z tym radzi.

ElGringoGrande
źródło
dlaczego pole e-mail nie może pozwolić na wartości zerowe i mieć ciąg zerowy - Mówiąc wprost : ponieważ każdy programista, który wie cokolwiek o bazach danych, nigdy nie spodziewałby się, że puste ciągi mające magiczne znaczenie. Próbujesz stworzyć własną magiczną wartość, która będzie reprezentować to, co zasadniczo istnieje w każdej bazie danych: koncepcję reprezentującą brak wartości. Po co wymyślać koło ponownie? Także idea NULLS jest daleka od starej szkoły. Wartości zerowe są kluczem do zrozumienia projektu relacyjnej bazy danych.
Thomas
LOL. Jak powiedziałem z perspektywy programisty, wartości zerowe są prawie zawsze uciążliwe i prawie nigdy nie są potrzebne dla LOGIKI BIZNESOWEJ. Jako programista osobiście nie dbam o projektowanie relacyjne. Gdybym to zrobił, byłbym kolesiem z DB. Jeśli dostaję wartość zerową z DB, prawie zawsze przekształcam ją w coś racjonalnego, na przykład pustego łańcucha, a następnie niech mój wspaniały projekt OOP robi magię. Ramy te zajmują się tymi głupimi zerami, które DBA narzucają światu. Wiem, że kolesie DB muszą sobie z tym poradzić i współczuję tobie. Ale jako programista nie muszę. Mam lepsze rozwiązania.
ElGringoGrande
„Nigdy” nie masz do czynienia z zerami. Opisujesz więc rozwiązanie strusi w połączeniu z rozwiązaniem magicznej wartości. „Zignoruję fakt, że istnieją nieobecne wartości i przekonwertuję wszystkie liczby całkowite zerowe na -1”. Aż nadejdzie dzień, kiedy -1 będzie prawdziwą wartością. Należy zauważyć, że jednym z powodów, dla których MS dodało składniki generyczne do platformy .NET, było rozwiązanie problemu ogromnego niedopasowania impedancji między bazami danych i kodem aplikacji, który przede wszystkim dotyczył wyrażania wartości zerowych w kodzie warstwy pośredniej. Te „głupie zera” istnieją również w logice biznesowej.
Thomas,
Fakt, że jakaś liczba całkowita jest nieobecna w db (lub jest zerowa), nie oznacza, że ​​muszę reprezentować ją jako -1 lub evan nullable (int). Jeśli uważasz, że to jedyny sposób radzenia sobie z zerami, to nie rozumiesz zbyt dobrze programowania. Pamiętaj, że null to nie to samo, co nic. Jak powiedziałeś, null reprezentuje miejsce dla nieobecnych wartości w jakiejś strukturze danych. To coś znaczy. Logika biznesowa rzadko (która nie jest taka sama jak nigdy) potrzebuje tej koncepcji, ponieważ dotyczy zachowania, a nie danych. A kiedy ma wartość zero, rzadko jest najlepszym sposobem na przedstawienie tego.
ElGringoGrande
Nawet logika biznesowa musi uwzględniać (czyli reprezentować) nieobecne wartości i jest to prawdą z mojego doświadczenia, w prawie każdym systemie, który widziałem lub budowałem w ciągu ostatnich 20 lat. Baza danych modeluje fakty biznesowe, które mają zostać przechwycone i zapisane. Jeśli logika biznesowa chce mieć możliwość interakcji z bazą danych, musi wiedzieć, jak radzić sobie z wartościami zerowymi. Nie ma znaczenia, czy jest to struktura niestandardowa, wartość magiczna czy ogólna. Logika biznesowa wymaga zdolności do obsługi odbierania nieobecnej wartości z bazy danych oraz możliwości oznaczenia wartości jako nieobecnej w bazie danych.
Thomas,
-1

Nie sądzę, żeby miało to duże znaczenie, ale bardziej podoba mi się, gdy jest tam NULL.

Kiedy przeglądam dane wyświetlane w tabeli (jak w SQL Server Management Studio), mogę lepiej odróżnić brakującą wartość, jeśli jest napisane NULL, a tło ma inny kolor.

Jeśli widzę puste miejsce, zawsze zastanawiam się, czy jest naprawdę puste, czy jest jakaś biała spacja lub jakieś niewidzialne znaki. Z NULL jest gwarantowana pusta na pierwszy rzut oka.

wprowadź opis zdjęcia tutaj

Zwykle nie rozróżniam wartości w aplikacji, ponieważ jest nieoczekiwane i dziwne, że NULL i pusty ciąg znaków oznaczają coś innego. Przez większość czasu podchodzę do defensywy i po prostu mam do czynienia z obydwoma stanami. Ale dla mnie, jako człowieka, NULL jest łatwiejszy do przetworzenia, patrząc na dane.

Tom Pažourek
źródło
wydaje się, że nie oferuje to nic istotnego w porównaniu z punktami poczynionymi i wyjaśnionymi w poprzednich 12 odpowiedziach
gnat
@gnat: Nie zgadzam się, nikt w odpowiedziach nie wspomniał jeszcze o aspekcie oglądania danych przez człowieka. Jest tylko jedna wartość NULL, ale może istnieć wiele wartości, które wyglądają jak pusty ciąg (nie tylko białe znaki, ale także mnóstwo dziwnie zachowujących się znaków Unicode). Nie widzę żadnej innej odpowiedzi dotyczącej tego aspektu problemu.
Tom Pažourek,
o ile wiem, zostało to dość dobrze ułożone w drugiej górnej odpowiedzi, która została opublikowana 5 lat temu: „Dla każdego programisty, który patrzy na bazę danych, jest oczywiste itp.” itp.
wt.
@gnat: Rozumiem twój punkt widzenia, chociaż myślę, że autor nie ma na myśli tego samego. Wydaje mi się, że bardziej mówi o tym, że NULL oznacza pola opcjonalne, ale dla wymaganych pól można również użyć pustego ciągu, dlatego NULL jest bardziej logiczny w przypadku braku wartości. Zgadzam się z nim. Ale moja odpowiedź wskazuje na to, że pusty ciąg nie jest tak jednoznaczny jak wartość NULL, ponieważ wiele rzeczy może wyglądać jak puste ciągi na pierwszy rzut oka, ale w rzeczywistości nie są pustymi ciągami.
Tom Pažourek,