‧
阅读时长4分钟
我们将问题嵌入您的问题中
Sameer Al-Sakran
‧ 阅读时长4分钟
分享此文章
Metabase查询构建器允许您在数据库中的单个表上运行简单查询。在此基本范例中，我们增加了从通过外键连接的表中提取信息、修改列以及基于数学表达式创建新列的功能。然而，这始终是我们坚持的核心模式，并在可用性方面带来了一些回报。
我们发现，虽然它不如其他一些工具功能强大，但它能让80%的非技术用户提出20%的问题，而市面上其他工具则专注于让公司中5%的精英用户提出80%的问题。
在此基础上，通过我们的新版本，您现在可以在查询构建器中将已保存的问题用作“表”。
这为什么有用？
显而易见的用例是对另一个问题的结果进行聚合或多维分析，例如“每日收入平均值”。更有趣的是，您可以使用已保存的问题（无论是GUI还是SQL问题）作为新问题的起点。
这允许您使用SQL生成复杂的中间结果（即子查询），然后在查询构建器中使用它。
其他工具会强制您创建庞大的SQL模板，或者使用奇怪的YAML专有语言来生成非技术用户可以使用的“重量级”工件。但通过嵌套查询，您可以使用标准SQL创建这些子查询，然后使用查询构建器。如果能有所预见地进行操作，这意味着您可以使用轻量级的纯SQL和查询构建器来暴露那些原本需要大量复杂SQL或YAML的接口。
关于连接（Join）呢？
现在，如果您想提出一个涉及两个或多个表的问题，请在嵌套子查询中使用连接。与其创建一个复杂的界面来促进连接，不如直接使用标准SQL。虽然内连接、外连接、左连接、右连接以及各种连接的细节确实微妙且可能复杂，但实际的SQL语法却相当简单。我们认为，任何了解左内连接和右外连接区别的人，也应该懂一些SQL，因此我们无需重新发明图形化工具。
这是否意味着您将不再为查询构建器添加更强大的功能？
完全不是。我们为查询构建器准备了许多功能！在即将发布的版本中，我们将大力推出更多功能，以满足非技术用户和技术用户的需求。这些功能将侧重于SQL不擅长而非SQL擅长的方面。我们还将重新设计界面，使其对非技术用户更易于访问，让他们更容易找到常见问题的起点。
这会很慢吗？
这取决于具体情况。您可能会生成一个慢查询，但即使您使用显式子查询，它也会很慢，而且我们发现我们的用户经常使用子查询。
如果我的用户运行太多复合查询导致速度变慢怎么办？
这意味着您的用户从运行这些查询中发现了价值，您应该对它们进行优化。优化的方法是将子查询转换为物化视图，如果物化视图（例如在插入时）仍然很慢，则将其分离到批处理或流式转换过程中，生成一个类似的表。我们建议保留相同的表名，因为这样可以原地替换查询。
接下来是什么？
我们建议您尝试一下嵌套查询，并向我们提供反馈。我们有许多开放议题，正在讨论后续步骤和改进措施：
如果其中一个或多个功能能显著简化您的工作，请在相关议题中发表意见。我们根据认为这些是好主意的用户数量来优先开发功能增强。
