Perché ANSI SQL definisce SUM (nessuna riga) come NULL?

Lo standard ANSI SQL definisce (capitolo 6.5, specifica della funzione set) il seguente comportamento per le funzioni aggregate su set di risultati vuoti:

COUNT(...) = 0
AVG(...) = NULL
MIN(...) = NULL
MAX(...) = NULL
SUM(...) = NULL

Restituire NULL per AVG, MIN e MAX ha perfettamente senso, poiché la media, il minimo e il massimo di un set vuoto non sono definiti.

L'ultimo, tuttavia, fastidi me: Matematicamente, la somma di un insieme vuoto è ben definita: 0. Usando 0, l' elemento neutro dell'aggiunta, come il caso base rende tutto coerente:

SUM({})        = 0    = 0
SUM({5})       = 5    = 0 + 5
SUM({5, 3})    = 8    = 0 + 5 + 3
SUM({5, NULL}) = NULL = 0 + 5 + NULL

La definizione SUM({})come nullfondamentalmente rende "senza righe" un caso speciale che non si adatta agli altri:

SUM({})     = NULL  = NULL
SUM({5})    = 5    != NULL + 5 (= NULL)
SUM({5, 3}) = 8    != NULL + 5 + 3 (= NULL)

C'è qualche ovvio vantaggio della scelta fatta (SUM essendo NULL) che mi sono perso?

Temo che il motivo sia semplicemente che le regole sono state impostate in modo ad hoc (come molte altre "caratteristiche" dello standard ISO SQL) in un momento in cui le aggregazioni SQL e la loro connessione con la matematica erano meno comprese di quanto non siano ora (*).

È solo una delle moltissime incongruenze nel linguaggio SQL. Rendono la lingua più difficile da insegnare, più difficile da imparare, più difficile da capire, più difficile da usare, più difficile per quello che vuoi, ma è così che vanno le cose. Le regole non possono essere modificate "a freddo" e "proprio così", per ovvi motivi di compatibilità con le versioni precedenti (se il comitato ISO pubblica una versione finale dello standard e i fornitori decidono quindi di implementare tale standard, tali fornitori non apprezzeranno molto se in una versione successiva, le regole sono cambiate in modo tale che le implementazioni esistenti (conformi) della precedente versione dello standard "non rispettano automaticamente" la nuova versione ...)

(*) Ora si comprende meglio che le aggregazioni su un set vuoto si comportano in modo più coerente se restituiscono sistematicamente il valore dell'identità (= quello che si chiama "elemento neutro") dell'operatore binario sottostante a portata di mano. L'operatore binario sottostante per COUNT e SUM è un'aggiunta e il suo valore di identità è zero. Per MIN e MAX, quel valore di identità è il valore più alto e più basso del tipo a portata di mano, rispettivamente, se i tipi interessati sono finiti. Tuttavia, casi come media, mezzi armonici, mediane, ecc. Sono estremamente intricati ed esotici in questo senso.

In senso pragmatico, il risultato esistente di NULLè utile. Considera la seguente tabella e le seguenti dichiarazioni:

C1 C2
-- --
 1  3 
 2 -1 
 3 -2 

SELECT SUM(C2) FROM T1 WHERE C1 > 9;

SELECT SUM(C2) FROM T1 WHERE C1 < 9;

La prima istruzione restituisce NULL e la seconda restituisce zero. Se un set vuoto restituisse zero perché SUMavremmo bisogno di un altro mezzo per distinguere una somma reale di zero da un set vuoto, magari usando count. Se vogliamo davvero zero per l'insieme vuoto, allora un semplice COALESCEfornirà quel requisito.

SELECT COALESCE(SUM(C2),0) FROM T1 WHERE C1 > 9;

La differenza principale che posso vedere è per quanto riguarda il tipo di dati. COUNT ha un tipo di ritorno ben definito: un numero intero. Tutti gli altri dipendono dal tipo di colonna / espressione che stanno guardando. Il loro tipo di ritorno deve essere compatibile con tutti i membri dell'insieme (think float, currency, decimal, bcd, timespan, ...). Poiché non esiste un set, non è possibile implicare un tipo restituito, quindi NULL è l'opzione migliore.

Nota: nella maggior parte dei casi è possibile implicare un tipo restituito dal tipo di colonna che si sta guardando, ma è possibile eseguire SUM non solo sulle colonne ma su tutti i tipi di cose. Imporre un tipo di ritorno potrebbe diventare molto difficile, se non impossibile, in determinate circostanze, specialmente quando si pensa a possibili espansioni dello standard (vengono in mente i tipi dinamici).