SQL对空集合处理的系统性缺陷清单

空集合（不包含元素的集合）在关系模型里是一个极其重要、行为完全普适一致的 基础概念（[[TABLE_DUM与TABLE_DEE关系代数中的0]]正是这份普适性最极致的 体现），但SQL在处理空集合的方式上散布着大量彼此不一致的特设规则，本节把 全书已经零散讨论过的多处空集合问题汇总成一份清单：VALUES表达式不允许空的 行表达式列表；SQL”集合函数”在参数为空时返回NULL（COUNT和COUNT(*)例外， 正确返回0，呼应[[SQL聚集运算符的三重缺陷]]）；标量子查询结果为空表时型转 为NULL，行子查询结果为空表时型转为全NULL的一行（呼应[[子查询三分类及空表 型转规则]]）；GROUP BY作用于分组列和被分组表都为空的情况时，理应产生 “零个分组”的结果，实际却产生”恰好一个（本质为空的）组”这个特例（呼应 [[SQL聚集运算符的三重缺陷]]）；键不能是空的列集合（外键更不行）；表不能 有空标题（呼应[[TABLE_DUM与TABLE_DEE关系代数中的0]]里”SQL没有0-元组、 没有TABLE_DUM/TABLE_DEE对应物”这条缺陷）；SELECT项列表不能为空；FROM项 列表不能为空；UNION/INTERSECT/EXCEPT CORRESPONDING里公共列的集合不能为空 （但JOIN本身可以没有公共列，即退化成积）；一行中不能有空的分量集合（即 SQL没有[[TABLE_DUM与TABLE_DEE关系代数中的0]]里0-元组的对应物）。这份清单 的价值不在于每一条本身的技术细节，而在于它把全书散落在各章的”SQL处理空 集合时的特设行为”集中呈现，让读者一次性看清SQL在这个基础概念上有多不 一致——书中坦承对大多数这类问题读者无能为力（这是SQL标准本身的设计缺陷）， 但至少应该清楚知道这些坑分别在哪里。

结构图：

flowchart TD
    A[空集合在SQL中的处理] --> B["VALUES不允许空行列表"]
    A --> C["集合函数(除COUNT)在空参数下返回NULL<br/>而非恒等值"]
    A --> D["标量/行子查询结果为空<br/>型转为NULL/全NULL行"]
    A --> E["GROUP BY空表<br/>产生1个空组而非0个组"]
    A --> F["键/外键不能是空列集合<br/>表不能有空标题"]
    A --> G["SELECT/FROM项列表不能为空"]
    A --> H["CORRESPONDING公共列不能为空<br/>(JOIN例外)"]
    A --> I["行不能有空分量集合<br/>即无0-元组对应物"]