如果一条 SQL 语句返回一个数据库，会怎样？
一种新的 SQL 扩展提议让查询返回一整组相关表——本质上是一个小型、归一化的“子数据库”——而不是单个反范式化结果表。支持者认为它对 ORM、层级数据、性能（减少传输中的重复数据）以及保留模式/键的信息都有好处，并将其类比为 GraphQL、Datomic 和范畴论数据库等思路。批评者则认为现有工具（连接、多次查询、JSON/JSONB、存储过程）已经覆盖了大多数用例，而且围绕“数据库”与“模式”的新术语和附加复杂性未必值得成为一种新的语言特性。
概念：“SELECT RESULTDB” / 返回类似数据库的结果
- 提议：扩展 SQL，使查询可以返回多个相关表（一个“数据库的子集”），而不是单个反范式化的结果集。
- 可以把它理解为一种“归一化连接”：你会得到涉及的每个表分别对应的关系，只包含相关行，并保留键/关系。
- 其目标是减少连接中的数据重复，并在结果中保留更多模式/键的信息。
动机与用例
- 性能：避免在大型连接结果中重复父表数据；尤其在父子/雪花模式中，可减少传输的数据量。
- ORM：更容易还原对象图（例如食谱和配料、订单和客户），而不必使用 N+1 查询或生成巨大反范式化连接。
- 延迟：一次往返即可获取多个相关关系，而不是发起很多查询。
- 一致性：单个查询可以提供相关数据的快照，而多次查询可能得到不一致的数据。
- 可能适合边缘数据库 / 本地镜像：获取一个“部分数据库”，用于离线或客户端侧查询。
批评与质疑
- 许多人认为现有工具已经足够：多次查询（可并行）、JSON/数组聚合、返回多个结果集的视图/存储过程、游标。
- 有人把反范式化的查询结果视为一种 特性：查询的职责是把数据塑造成所需格式，而不是镜像模式。
- 担心在内存中构造一个“结果数据库”只是把复杂性转移到客户端，客户端随后还得再次对其查询。
- 一些人认为论文误解或曲解了关系模型，或者把“关系型”与 SQL 的局限混为一谈。
- 还有人认为这只是对打包/拆包多个关系的语法糖。
相关技术与前例
- 与 GraphQL、JSON:API、SQL JSON/JSONB 支持、SQL Server 的
FOR JSON、ODBC/MARS 多结果集、Akiban 的“嵌套结果集”作比较。 - 也提到范畴论中的“查询作为数据库之间的态射”，以及图/Datalog 系统和类似 Datomic 的“数据库即值”理念。
未决问题与歧义
- 线程中讨论了键、外键和聚合（例如 SUM、MAX）在多表结果中的精确语义，但尚未完全定论。
- 这种方法相较于压缩和现有模式能带来多大实际收益，仍有争议，也尚不清楚。