Почему ANSI SQL определяет SUM (без строк) как NULL?

Стандарт ANSI SQL определяет (глава 6.5, спецификация функции набора) следующее поведение для агрегатных функций в пустых результирующих наборах:

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

Возврат NULL для AVG, MIN и MAX имеет смысл, поскольку среднее, минимальное и максимальное значения пустого набора не определены.

Последний, однако, беспокоит меня: Математически SUM пустого множества хорошо определен: 0. Использование 0, нейтрального элемента сложения, в качестве базового варианта делает все согласованным:

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

Определение SUM({})as в nullосновном делает «без строк» ​​особым случаем, который не вписывается в другие:

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

Есть ли какое-то очевидное преимущество сделанного выбора (SUM, NULL), который я пропустил?

Я боюсь, что причина в том, что правила были установлены по принципу ad hoc (как и многие другие «особенности» стандарта ISO SQL) в то время, когда агрегаты SQL и их связь с математикой были менее понятны, чем сейчас (*).

Это всего лишь одна из чрезвычайно многих несоответствий в языке SQL. Они делают язык труднее учить, труднее учить, труднее понять, труднее использовать, труднее всего, что вы хотите, но это просто так. Правила не могут быть изменены «холодными» и «просто так» по очевидным причинам обратной совместимости (если комитет ИСО публикует окончательную версию стандарта, а поставщики затем собираются внедрить этот стандарт, то эти поставщики не оценят это очень сильно, если в последующей версии правила изменяются так, что существующие (совместимые) реализации прежней версии стандарта «автоматически не соответствуют» новой версии ...)

(*) Теперь лучше понять, что агрегаты по пустому набору ведут себя более согласованно, если они систематически возвращают значение идентичности (= то, что вы называете «нейтральным элементом») базового бинарного оператора под рукой. Этот базовый двоичный оператор для COUNT и SUM является сложением, а его значение идентичности равно нулю. Для MIN и MAX это значение идентификатора является наивысшим и наименьшим значением имеющегося типа, соответственно, если рассматриваемые типы конечны. Однако случаи, такие как усреднение, гармонические средние, медианы и т. Д., Чрезвычайно сложны и экзотичны в этом отношении.

В прагматическом смысле существующий результат NULLполезен. Рассмотрим следующую таблицу и утверждения:

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

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

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

Первый оператор возвращает NULL, а второй возвращает ноль. Если бы пустой набор возвратил ноль, SUMнам понадобится другое средство, чтобы отличить истинную сумму нуля от пустого набора, возможно, используя count. Если мы действительно хотим ноль для пустого множества, то простое COALESCEбудет соответствовать этому требованию.

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

Основное различие, которое я вижу, это тип данных. COUNT имеет четко определенный тип повторения: целое число. Все остальные зависят от типа столбца / выражения, на которое они смотрят. Их тип возвращаемого значения должен быть совместим со всеми членами набора (например, с плавающей точкой, валютой, десятичной дробью, bcd, timespan, ...). Поскольку нет набора, вы не можете подразумевать тип возвращаемого значения, поэтому NULL - ваш лучший вариант.

Примечание. В большинстве случаев вы можете подразумевать тип возвращаемого значения для типа столбца, который вы просматриваете, но вы можете делать SUMs не только для столбцов, но и для всех видов вещей. Подразумевать, что тип возврата может быть очень трудным, если не невозможным, при определенных обстоятельствах, особенно когда вы думаете о возможных расширениях стандарта (на ум приходят динамические типы).