关系型数据库RDBMS的查询语言SQL出现于上世纪80年代，并且已经迭代了很多版本（平均每3-4年一次大迭代），其中最知名的非SQL-92、99莫属，例如：

• 92版中在FROM语句中增加了子查询（subquery）功能
• 99版中增加了CTE（Common Table Expression）功能

SQL-92的子查询功能

SQL-92的CTE功能

上述两项功能虽然在原先基础上极大的增加了关系型数据库的灵活性（如上图所示），但SQL始终有一个很突出的弱点，就是对递归型数据结构（Recursive data structures），即关联关系的查询的支持非常差。由此引发的关系型数据库系统RDBMS与SQL的问题可以归纳总结如下：

• 多维关联、递归查询的SQL代码极为复杂
• 多表关联查询效率极低，很难实时进行
• 复杂查询可解释性差，存储进程“黑盒”
• 由集中式改造为分布式架构也很难应对金融场景中的“长链”交易、复杂查询等

关系型数据库（数仓、数湖）遇到的问题

以上这些问题的本质是关系型数据库在实现关联查询时不得不依赖表连接（table-join）操作，每一次多表关联都意味着潜在的表扫描操作，以及因为“笛卡尔积”问题而导致的性能的指数级下降和SQL语句、代码的复杂度的直线上升。特别是在牵涉到大表时的笛卡尔积问题，会让计算复杂度以乘积的方式增长。

举个具体而常见的例子，在银行业中的指标计算与归因分析，会涉及明细数据、分行-支行、条线、客户经理、指标子项、客户账户信息等多个维度的综合计算。用SQL和关系型数据库来计算的复杂度是个天文数字；而用图计算来建模和实现，是加和而非乘积的关系——两者之间存在着指数级的性能差异。换言之，用SQL来实现，会耗费大量的计算、存储资源，并且效率非常低下，甚至无法完成。但是用图计算来实现，可以做到实时，并且耗费很少的资源——更低的TCO，更高的ROI。这就是图数据库的颠覆性优势之一——性能。

关系型数据库（数仓、数湖）中表连接导致的笛卡尔积