Чому 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({})як nullпринципу "не містить рядків" особливий випадок, який не вписується в інші:

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

Чи є якась явна перевага вибору, який я був зроблений (SUM - NULL), який я пропустив?

Я боюся, що причина полягає лише в тому, що правила встановлювались по-різному (як і багато інших "особливостей" стандарту ISO SQL) у той час, коли агрегації SQL та їх зв'язок з математикою були менш зрозумілі, ніж зараз (*).

Це лише одна з надзвичайно багатьох невідповідностей у мові SQL. Вони ускладнюють викладання мови, важче вивчати, важче зрозуміти, складніше використовувати, важче для всього, що ви хочете, але це просто так. Правила не можуть бути змінені "холодно" та "просто так" з очевидних причин відсталої сумісності (Якщо комітет ISO опублікує остаточну версію стандарту, а постачальники потім налаштовані на впровадження цього стандарту, то ці постачальники не оцінять їх дуже важливо, якщо в наступній версії правила змінюються таким чином, що існуючі (сумісні) реалізації колишньої версії стандарту "автоматично не відповідають" новій версії ...)

(*) Тепер краще зрозуміти, що агрегації над порожнім набором поводяться більш послідовно, якщо вони систематично повертають значення ідентичності (= те, що ви називаєте "нейтральним елементом") базового бінарного оператора. Цей базовий двійковий оператор для 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нам знадобиться інший спосіб, щоб відрізнити справжню суму нуля від порожнього набору, можливо, використовуючи підрахунок. Якщо ми справді хочемо нуля для порожнього набору, то простий COALESCEзабезпечить цю вимогу.

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

Основна відмінність, яку я бачу, стосується типу даних. COUNT має чітко визначений тип повернення: Ціла кількість. Всі інші залежать від типу стовпця / виразу, який вони дивляться. Їх тип повернення повинен бути сумісним з усіма членами набору (think float, валюта, десяткова, bcd, проміжок часу, ...). Оскільки немає набору, ви не можете припустити тип повернення, тому NULL - ваш найкращий варіант.

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