原文作者 Elvis Pranskevichus（@elprans）是我老板，原文《We Can Do Better Than SQL》发布于 2019 年 5 月 9 日。EdgeDB 将在农历虎年正月初十举办 1.0 版本线上发布会，欢迎在掘金和 OSCHINA 关注我们，共迎后 SQL 时代的黎明。

（作为 EdgeDB 的开发者，）我们经常碰到这样的问题：“（你们）为什么要创造一种新的查询语言？”“SQL 它不香吗？”答案就在这篇文章里。开始之前，我们先回顾一下关系模型和 SQL 的诞生历史。

关系模型与 SQL 简史

埃德加·科德在 1970 年的论文《大型共享数据池中的关系模型》[1]中正式引入了“关系模型”的概念，假定一种叫做“关系”的元组集合足以表达数据库中的所有数据。为了描述数据库查询，他还发明了一种一阶谓词逻辑：元组关系演算。

科德的想法在当时是颠覆性的，因为这是有史以来第一次，人们可以用一种简洁一致的数学模型，来描述一个数据库，和一种通用查询语言。自然而然地，越来越多的人对此产生了兴趣并展开了进一步的研究。更重要的是，人们开始有意义地尝试实现关系模型。

1974 年，唐纳德·钱柏林和雷蒙德·博伊斯发表了一篇论文[2]，引入了“与一阶谓词逻辑有同样效力的……用于表结构的一组简易运算”（译注：也就是 SQL，论文里还是 SEQUEL）。当时他们感觉到，对于“没有接受过正规数学或计算机编程训练的用户”来说，学界提出的严格关系查询语言太晦涩难懂，并认为“该语言（SQL）大概八成是要用来做临时查询”[3]，也就是说，他俩起初并没有把 SQL 当做是一门“正儿八经”的语言。然而无独有偶，对关系模型的商业应用抱有极大兴趣的 IBM 公司，迅速拾起了这门技术，并快速将其产品化；其迅速崛起的竞争对手 Oracle 公司也紧随其后地采用了 SQL 技术。

在当时，IBM 对科技市场有着举足轻重的影响力，所以 SQL 很快就成为了关系数据库的事实标准，并在随后的 1989 年成为了美国国家标准学会（ANSI）发布的正式标准。ANSI 的标准基本上是按照当时的几大 SQL 实现划定的，该标准的后续版本也没能逃脱商业公司的决定性影响。

现如今，SQL 已然成为使用最广泛的数据库语言，但那并不意味着我们应止步于此。实际上，这门语言有着一箩筐的严重问题，因为其最初就是按照“简易临时”的用途来设计的，再加上后来竞争厂商们本着“先做出来再设计”的原则，对 SQL 标准的设计更是雪上加霜。

对 SQL 的批评

包括科德本人[4]在内的许多专家都对 SQL——尤其是其早期版本——提出了严厉的批评，还有克里斯托佛·达特也发表了大量批评 SQL 的论文和书籍[5][6][7]。在后续版本的标准中，虽然许多早期缺点得到了弥补，但是另一些严重的问题却变得更加根深蒂固。

以 PostgreSQL 为例，SQL 的“罪状”主要可归为以下四类，其中一些适用于所有 SQL，另一些则只是针对特定实现：

• 正交性设计不合理——SQL 语句很难写；
• 不够紧凑——SQL 语言里废话太多；
• 一致性太差——SQL 在语法和语义上不够一致；
• 集成度不足——SQL 不能很好地融入应用程序语言与通讯协议。

正交性设计不合理

在编程语言中“正交”的意思是，你可以用相对固定的几种不同的方式，来拼装一个相对精简的基础语法集。如果一门语言的正交性设计得好，那么它应该是小巧的、有规律可循的，并且因为语法规则的特殊情况较少，所以十分容易学习和上手。相反地，如果正交性的设计不合理，你就会看到一个臃肿的语言，充满了各种特殊用法和注意事项。

举一个正面的例子，如果你把一个表达式中的任意部分，替换成一个变量或是函数调用，最后结果却没有任何影响，那么这种编程语言就算是有良好的正交性。

但是在 SQL 语言中，实现类似的替换却遥不可及，因为 SQL 定义了两种互相不兼容的表达式：

• Table 表达式返回一个表：SELECT * FROM table
• Scalar 表达式返回一个单独的标量值：SELECT count(*) FROM table

Table 表达式只能用于 FROM 从句、函数或某些仅针对 Table 表达式的运算符，而更糟糕的是，Scalar 表达式往往有着与 Table 表达式一模一样的语法，让人感觉是糊涂他妈给糊涂开门——糊涂到家了。比如说，现在我们要列出全公司部门领导的姓名，查询语句可以这样写：

SELECT name

FROM emp

WHERE role = '部门领导'

接着需求变了，要求把领导姓名列表合并到部门信息的查询中。那么按照直觉，就应该把上面的姓名列表做成一个子查询，添加到部门查询的父语句中：

SELECT

    dept.name,

    ...

    (SELECT name FROM emp

     WHERE role = '部门领导' AND deptno = dept.no)

FROM

    dept

    ...

这看似没什么毛病，也能跑出结果，但仅限于每个部门只有一个领导的情况。当子查询返回了多个结果时，这条 SQL 就挂了。为了应对多个领导（的情况），我们只能用 JOIN 来重写这条查询：

SELECT

    dept.name,

    ...

    head.name

FROM

    dept

    INNER JOIN emp AS head

        ON (head.deptno = dept.no

            AND head.role = '部门领导')

    ...

而此时的结构已经与最初相差甚远了，要想达到 SQL 源码级别的重用，基本不太现实。

不够紧凑

没人会说 SQL 是一门优雅的正交性语言。更有甚者把 SQL 比作是泥足巨象——每次增加新功能，大象就越胖、越不稳定。SQL 的标准化就是数据库厂商的游乐场，他们对无利益瓜葛的学者或有兴趣参与的用户不屑一顾。[8]

————保罗·阿切尼等人

SQL 语言十分臃肿，在撰写本文时（2019 年中），PostgreSQL 实现了 469 个关键字，而这只是 SQL:2016 标准中的第二部分，而完整的标准一共有 14 个部分，1732 页。

而这其中最主要的原因是，SQL 想要成为一种类似英语的语言，以达到“非专业人士”也能使用的最初设想。然而随着 SQL 语言的发展，这种语言上冗长的模仿，逐渐变成了编写和理解 SQL 语言的障碍。COBOL 已经给我们上过这一课了，人们早就转向更新颖、更简洁的编程语言了。

SQL 如此啰嗦难读，除了因为关键字的“增生症”，之前提到的正交性问题也做出了不小的贡献。

一致性太差

SQL 语言在语法和语义上都很任性地缺乏一致性，而更糟糕的是，不同的数据库还创造了他们自己版本的 SQL，而这些 SQL 变种之间通常又互不兼容。

来看几个完全不一样的调用方式：

SELECT substring('PostgreSQL' from 8 for 3);

SELECT substring('PostgreSQL', 8, 3); -- PostgreSQL 特有语法



SELECT trim(both from 'yxSQLxx', 'xyz');

SELECT extract(day from timestamp '2001-02-16 20:38:40');

在聚合函数中指定排序方式，可以这样：

SELECT array_agg(foo ORDER BY bar)

也可以这样：

SELECT rank(foo) WITHIN GROUP (ORDER BY bar)

此等不一致罄竹难书，本文就到此打住了。

NULL——惊不惊喜意不意外

在某些数据缺失的情况下，人们会把缺少完美的处理方式，错误地归罪与关系模型本身。但其实，问题的根源在于 SQL 自己的缺陷，及其别扭地操作关系模型的方式。[4]

——埃德加·科德

很多人都说 NULL 是 SQL 设计的一大败笔[6][9][10]，但实际情况更糟糕，以至于要用一个单独的章节来解释，现今这些 SQL 实现对 NULL 的处理是多么的惊人、危险和不一致。

NULL 十分特殊，特殊到它不等于任何值，包括它自己：

postgres=# select NULL = NULL;

 ?column?

----------



(1 row)

实际上，对 NULL 做几乎任何操作都会返回 NULL，并且对结果产生微妙的影响：

postgres=# CREATE TABLE x (a int, b text);

CREATE TABLE

postgres=# INSERT INTO x(a, b)

           VALUES (1, 'one'), (2, 'two'), (NULL, 'three')

           RETURNING a, b;

 a |   b

---+-------

 1 | one

 2 | two

   | three

(3 rows)



postgres=# SELECT * FROM x WHERE a NOT IN (1, null);

 a | b

---+---

(0 rows)

但在另一些情况下，NULL 觉得自己又行了，比如在 DISTINCT 中：

elvis=# SELECT DISTINCT *

        FROM (VALUES (1), (NULL), (NULL)) AS q;

 column1

---------



       1

(2 rows)

或是 UNION：

elvis=# VALUES (1), (NULL) UNION VALUES (2), (NULL);

 column1

---------



       1

       2

(3 rows)

在 SQL 的真假表达式中，大部分传统逻辑和布尔代数碰到 NULL 都会出幺蛾子。比如排中律 P∨¬P 就拿 NULL 没办法：

postgres=# SELECT count(*) FROM x WHERE a = 1 OR a != 1;

 count

-------

     2

(1 row)

然而没有最糟，只有更糟：

postgres=# SELECT

               b,

               CASE WHEN a = 1

               THEN '是 1'

               ELSE '不是 1'

               END

           FROM x;

   b   |  case

-------+---------

 one   | 是 1

 two   | 不是 1

 three | 不是 1

(3 rows)



postgres=# SELECT

               b,

               CASE WHEN a != 1

               THEN '不是 1'

               ELSE '是 1'

               END

           FROM x;

   b   |  case

-------+---------

 one   | 是 1

 two   | 不是 1

 three | 是 1

(3 rows)

于是乎 b = three 这一行就变成了薛定谔的 1，尽管两个 CASE 表达式看起来是等价的。

含有 NULL 的数据对统计学来说也是一个神秘的存在：

postgres=# SELECT count(a) FROM x;

 count

-------

     2

(1 row)



postgres=# SELECT cardinality(array_agg(a)) FROM x;

 cardinality

-------------

           3

(1 row)



postgres=# SELECT count(*) FROM x;

 count

-------

     3

(1 row)

你无法比较含有 NULL 值的两行数据：

postgres=# SELECT (NULL, 1) = (NULL, 1);

 ?column?

----------



(1 row)

甚至连 IS NULL 都不管用：

postgres=# SELECT (NULL, 1) IS NULL;

 ?column?

----------

 f

(1 row)



postgres=# SELECT (NULL, 1) IS NOT NULL;

 ?column?

----------

 f

(1 row)

更糟糕的是，数据库经常会用 NULL 来指示一种错误状态，有时候你不想 NULL 也 NULL 了：

postgres=# SELECT (ARRAY[1, 2])[3];

 array

-------



(1 row)



postgres=# SELECT to_char(timestamp '2001-02-16 20:38:40', '');

 to_char

---------



(1 row)

除数为零，PostgreSQL 还会抛出一个异常，MySQL 索性直接 NULL 了：

mysql> SELECT 1 / 0;

+-------+

| 1 / 0 |

+-------+

|  NULL |

+-------+

1 row in set, 1 warning (0.00 sec)

以上只是冰山一角，而且 NULL 的行为在同一 SQL 实现中都无法做到一致，更别提不同的实现了。

即便这样又如何呢？

OK，讲完了 SQL 的种种缺点，回头看我们也与它们共存了这么多年了，那到底有什么要紧的呢？其实这是一个人类工效学的问题（译注：虽然是同一个词“ergonomics”，但这里不是指鼠标电竞椅这类人体工学硬件，而是符合人类思维直觉的、能提高开发效率的软件）。对于一种编程语言，要想让任何水平的开发者、任何大小的团队以及任何复杂度的项目，都能轻松上手和高效利用，语言的正交性、紧凑性与一致性都是必不可少的先决条件。

我们已经习惯了编程语言令人耳目一新的快速发展，诸如 Swift、Rust、Kotlin 和 Go 这样的榜样都极大地推动了工程师的开发效率和生产力，然而 SQL 语言却能持续霸榜近 50 年，通常还有层层 ORM 和各种框架为它打掩护。

在对 SQL 数据库停滞不前的抱怨中——从一定程度上讲——人们发起了 NoSQL 运动。但不幸的是，NoSQL 不光丢弃了 SQL 语言，还放弃了关系数据库中许多有价值的东西，比如关系模型。

EdgeQL：查询语言的进化

对于表示数据，关系模型仍然是最普遍和有效的方法；而在 SQL 中，声明式的语法和与存储无关的概念依然闪闪发光。对于这两条，我们并不需要彻底放弃，我们真正需要的是一个“更好的 SQL”：一种更加简洁一致，同时又能让使用者如虎添翼的查询语言。

这就是我们创造 EdgeQL 所追寻的目标，在不影响正确性的同时，专注于易用性和综合性能，不惜花费数年时间用来做研发。下面我会展开介绍一些亮点，看我们是如何解决前面提到的各种问题的。

正交性、一致性与紧凑性

在 EdgeQL 里，任何值都是一个集合，任何表达式都是一个集合到集合的函数。这意味着从语法上来讲，在不改动其他部分的前提下，EdgeQL 语句中的任何表达式都可以提炼并替换成一个视图或函数调用。

比如说一个用来渲染电影列表及其评论数量的查询：

SELECT Movie {

    description,

    number_of_reviews := count(.reviews)

};

如果需要所有电影的平均评论数量，可以这么组合：

SELECT math::mean(

    Movie {

        description,

        number_of_reviews := count(.reviews)

    }.number_of_reviews

);

如果还需要一个单部电影的最高评论数量，可以继续组合：

SELECT (

    avg := math::mean(

        Movie {

            number_of_reviews := count(.reviews)

        }.number_of_reviews

    ),

    max := max(

        Movie {

            number_of_reviews := count(.reviews)

        }.number_of_reviews

    )

);

略显笨重？那就重构一下，把 Movie 表达式提取为一个视图：

WITH

    MovieReviewCount := Movie {

        number_of_reviews := count(.reviews)

    }

SELECT (

    avg := math::mean(MovieReviewCount.number_of_reviews),

    max := max(MovieReviewCount.number_of_reviews),

);

因为一切都是集合上的函数，所以 EdgeQL 仅有屈指可数的几个关键字，勾勒出查询语句的主体结构。

缺失数据的处理

EdgeQL 对于缺失数据的处理方式十分简单：“没有”就是一个空集，对空集的操作结果同样还是一个空集：

edgedb> SELECT True OR <bool>{};

{}

edgedb> SELECT True AND <bool>{};

{}

聚合函数的行为也是一致的：

edgedb> SELECT count({});

{0}

edgedb> SELECT array_agg(<str>{});

{[]}

在 EdgeQL 中，集合是一维的，也就是说，集合中不能有集合，包括空集：

edgedb> SELECT {1, {2, 3}, {}, {}};

{1, 2, 3}

上面这种集合构造的方法等价于使用 UNION 运算符，下面的例子更能凸显其集合的本质：

edgedb> SELECT {1} UNION {2, 3} UNION <int32>{} UNION <int32>{};

{1, 2, 3}

空集也可以通过结合运算，变成非空集：

edgedb> WITH empty_set_expr := <int64>{}

....... SELECT empty_set_expr ?? {1, 2};

{1, 2}

edgedb> WITH empty_set_expr := <int64>{}

....... SELECT {1, 2, 3} IF EXISTS empty_set_expr ELSE 42;

{42}

系统集成

EdgeDB 使用了一种十分接近现代应用开发风格的数据模型定义方式，这让应用程序与数据库之间数据模型的映射关系变得直观高效。

与 SQL 不同，EdgeQL 可以轻松地封装出任意的数据结构：

SELECT Movie {

    description,



    directors: {

        full_name,

        image,

    }

    ORDER BY .last_name,



    cast: {

        full_name,

        image,

    }

    ORDER BY .last_name,



    reviews := (

        SELECT Movie.<movie[IS Review] {

            body,

            rating,

            author: {

                name,

                image,

            }

        }

        ORDER BY .creation_time DESC

    ),

};

配合上大量 JSON 功能的加持，REST 和 GraphQL 后端的开发将变得异常简单。

写在最后

为了让非开发人员也能高效地操作关系数据，人们创造了 SQL。抛开缺点来看，SQL 语言可以说是取得了巨大的成功，大部分数据库都实现或模拟了 SQL。然而技术的进步是不可阻挡的，随着不断增长的新型需求、使用方式和开发效率，SQL 本身也面临着后劲不足的问题。是时候做点什么了。

1. Codd E. F., “A relational model of data for large shared data banks”, Communications of the ACM CACM, 13(6):377-387, 1970
2. Chamberlin D. D, Boyce R. F., “SEQUEL: A Structured English Query Language”, ACM SIGFIDET 1974, pp 249-264.
3. Chamberlin D. D, “Early History of SQL”, IEEE Annals of the History of Computing, 34(4):78-82, 2012
4. Codd E. F., “The relational model for database management: version 2” Addison-Wesley, Mass. 1990.
5. Date C. J., “A critique of the SQL database language”, ACM SIGMOD Record 14(3):8-54, 1984.
6. Date C. J., “Where SQL falls short”, Datamation 33(9):83-86, 1987.
7. Date C. J., “SQL and Relational Theory”, O’Reilly, 2009.
8. Atzeni P. et al., The relational model is dead, SQL is dead, and I don’t feel so good myself. ACM SIGMOD Record, 42(2):64-68, 2013.
9. Codd E. F., “More commentary on missing information (applicable and inapplicable information)”, ACM SIGMOD Record 16(1):42-47, 1987.
10. Date C. J., “Null Values in Database Management. In Relational Databases: Selected Writings”, Addison-Wesley, Mass. 1986.