问题中的问题

Metabase 查询构建器允许您在数据库中的单个表上运行简单查询。在这个基本用法中，我们增加了从外键链接的表中提取信息、修改列以及基于数学表达式创建新列的功能。然而，这一直是我们坚持的核心模式，并在可用性方面取得了一些回报。

我们发现，虽然它没有其他一些工具那么强大，但它确实让 80% 的非技术用户能够提出 20% 的问题，而其他所有工具都专注于让公司中 5% 的精英提出 80% 的问题。

在此基础上，通过我们的新版本，您现在可以使用已保存的问题作为查询构建器中的“表”。

这有什么用？

显而易见的用例是聚合或切片和切块另一个问题的结果，例如“每日收入的平均值”。更有趣的是，您可以使用已保存的问题（GUI 或 SQL 问题）作为新问题的起点。

这使您可以使用 SQL 生成复杂的中间结果（又名子查询），然后在查询构建器中使用它。

其他工具迫使您要么制作真正庞大的 SQL 模板，要么使用怪异的 YAML 专有语言来生成您的非技术用户可以使用的“重型”工件。但是使用嵌套问题，您可以使用标准 SQL 创建这些子查询，然后使用查询构建器。如果事先有所预见，这意味着您可以使用轻量级的原始 SQL 和查询构建器来公开原本需要大量怪异 SQL 或 YAML 的界面。

连接呢？

现在，如果您想提出一个涉及两个或多个表的问题，请在嵌套子问题中使用连接。与其创建复杂的界面来促进连接，不如直接使用标准 SQL。虽然内部连接、外部连接、左连接、右连接、向上、向下和所有周围连接的复杂性确实很微妙且可能很复杂，但实际的 SQL 语法却相当简单。我们认为，与其重新发明图形轮，不如让任何知道左内连接和右外连接之间区别的人也了解一些 SQL。

这是否意味着您不会向查询构建器添加更强大的功能？

完全不是。我们为查询构建器准备了很多东西！在即将发布的版本中，我们将大力推动为非技术用户和技术用户公开更多功能。它们将侧重于 SQL 不擅长的方面，而不是 SQL 真正擅长的方面。我们还将重新设计界面，使其对非技术用户更易于访问，使他们更容易找到问题的常用起点。

这不会很慢吗？

这取决于情况。您可能会生成一个慢查询，但如果您也使用了显式子查询，它也会很慢，我们发现我们的用户倾向于经常使用这些查询。

如果我的用户运行太多复合查询并降低了速度怎么办？

这意味着您的用户发现运行这些查询的价值，您应该优化它们。优化的路径是将子查询转换为物化视图，如果这样做速度很慢（例如，在插入时），则将其分离到批处理或流式转换过程中，以生成类似的表。我们建议保留相同的表名，因为这样可以让您有可能就地替换查询。

下一步是什么？

我们建议您试用嵌套查询并给我们一些反馈。我们有许多未解决的问题，我们正在讨论后续步骤和改进

• 在 SQL 中使用嵌套查询的功能？
• 手动指定嵌套查询的元数据的功能？
• 在嵌套 SQL 查询中传递外键。
• 改进自动扫描查询结果以填充我们的元数据。
• 创建问题的物化视图的能力。

如果其中一个或多个功能可以大大简化您的生活，请在问题上发表意见。我们根据有多少用户也认为它们是好主意来确定功能增强的优先级。