Dlaczego wartości NULL są najpierw sortowane?

Dlaczego jest tak, że gdy mamy wartość NULL w kolumnie i sortujemy według wartości rosnąco, wartości NULL są najpierw sortowane?

select 1 as test
union all
select 2
union all
select NULL
union all
select 3
union all
select 4
order by test

prowadzi do

NULL
1
2
3
4

Ciągle myślę, że NULL oznacza „Nieokreślony” lub możliwy „Nieznany”. Jeśli to prawda, czy nie posortują na końcu, ponieważ wartość może być większa niż wszystkie inne wartości? (Czy jest to gdzieś opcja sortowania?)

Korzystam z SQL Server 2008R2, ale podejrzewam, że dotyczy to wszystkich serwerów SQL i prawdopodobnie wszystkich RDBMS.

BOL : Wartość NULL wskazuje, że wartość jest nieznana. Wartość NULL różni się od wartości pustej lub zerowej. Żadne dwie wartości zerowe nie są równe. Porównania między dwiema wartościami null lub między wartością NULL a dowolną inną wartością zwracają wartość nieznaną, ponieważ wartość każdej wartości NULL jest nieznana.

NULL oznacza nieznany. Żadna inna interpretacja nie jest ważna.

Jeśli to prawda, czy nie posortują na końcu, ponieważ wartość może być większa niż wszystkie inne wartości?

Nie może być . Nie ma żadnej potencjalnej wartości. Nieznany jest nieznany jest nieznany.

Jeśli chodzi o to, dlaczego pojawia się jako pierwsza, a nie ostatnia, nie jest to uwzględnione w opublikowanych standardach SQL i niestety jest pozostawione do uznania dostawcy RDBMS:

Wikipedia : Standard SQL nie definiuje jawnie domyślnej kolejności sortowania dla wartości Null. Zamiast tego w systemach zgodnych wartości Null można sortować przed lub po wszystkich wartościach danych, używając odpowiednio klauzul NULLS FIRST lub NULLS LAST z listy ORDER BY. Jednak nie wszyscy dostawcy DBMS wdrażają tę funkcję. Dostawcy, którzy nie implementują tej funkcji, mogą określić różne sposoby sortowania zerowego w DBMS.

Masz rację, co NULLmoże oznaczać „Nieokreślony” lub „Nieznany” lub „Jeszcze nie wiadomo” lub „Nie składać wniosku”. Ale nie ma powodu, aby stawiać Nulls na pierwszym miejscu lub na końcu. Jeśli nie znamy rzeczywistych wartości, to może być mały lub duży.

Myślę, że standardem określającym pożądane zachowanie wartości Null podczas sortowania jest:

ORDER BY 
    test NULLS LAST                      --- or NULLS FIRST for the opposite

Niestety SQL Server nie przyjął jeszcze tej składni. Jeśli się nie mylę, PostgreSQL i Oracle mają to.

Jedno rozwiązanie:

ORDER BY 
     CASE WHEN test IS NOT NULL 
            THEN 0 
          ELSE 1 
     END 
   , test

Kolejne rozwiązanie, które wymaga korekty w zależności od typu danych - ale nie będzie dobrze działać, ponieważ nie można użyć indeksu na (test):

ORDER BY 
    COALESCE(test, 2147483647)               --- if it's a 4-byte signed integer

Nie wiem, dlaczego tak się dzieje, ale z definicji NULLS nie może być porównywany z nie-NULLS, więc albo muszą iść na początku, albo na końcu (odpowiedź Marka opisuje to bardziej szczegółowo).

Aby uzyskać pożądane zachowanie - O ile mi wiadomo, nie ma opcji sortowania, aby pozostawić wartości zerowe na końcu, więc musisz je wyeliminować za pomocą kolumny obliczeniowej, aby wymusić je na końcu. Jednak w SQL Server nie można sortować według kolumny obliczeniowej ( CASE WHEN ...), gdy dane zawierają operator ustawiania ( UNION ALL). Więc:

CREATE TABLE #sorttest(test int)
INSERT INTO #sorttest values(1)
INSERT INTO #sorttest values(5)
INSERT INTO #sorttest values(4)
INSERT INTO #sorttest values(NULL)
INSERT INTO #sorttest values(3)
INSERT INTO #sorttest values(2)
SELECT test
FROM #sorttest
ORDER BY CASE WHEN test IS NULL THEN 1 ELSE 0 END, test

DROP TABLE #sorttest

Działa do sortowania wartości zerowych na końcu. Jeśli musisz użyć UNION(lub EXCEPTlub INTERSECTS) do wygenerowania zestawu danych, zrzuć dane do tymczasowej tabeli, jak wyżej.

Jeśli masz do czynienia z liczbami, możesz także użyć

ORDER BY -test DESC

NULLsą najniższymi możliwymi wartościami, dlatego DESCumieszcza je na końcu. W międzyczasie wartości niepuste mają odwrócony znak, więc w DESCrzeczywistości jest to ASCwartość rzeczywista. Powinno to być szybsze niż CASEi przypuszczam, że optymalizator zapytań może również używać indeksów w testkolumnie.