片段 vs. 已保存的问题 vs. 视图

本文概述了 Metabase 提供的用于整理 SQL 代码的工具，并就何时选择某种工具提供了指导。

整理 SQL 代码主要有两种工具：片段和已保存的问题。我们还将讨论数据库视图，以区分它们与 Metabase 中已保存问题的使用，尽管视图是特定于您的数据库（即，它们不属于 Metabase）。

片段和已保存的问题都可以作为模板注入到其他 SQL 问题中。至于何时使用哪种工具，经验法则是：对于小的、常用的 SQL 片段使用片段，对于您想独立执行的任何代码则使用已保存的 SQL 问题。

片段和文件夹

使用 片段 来处理关键或常用 SQL 代码。片段应该是简短、可重用的 SQL 代码行。

就像您可以使用 查询构建器 将官方聚合和筛选器定义为 度量和分段 一样，您可以使用片段来规范 KPI 和筛选器。例如，您可能希望精确存储收入的计算方式，或者活跃用户的定义。将该 SQL 代码保存为片段，添加描述（您甚至可以包含您的联系方式，以防有人提问），您的团队中的每个人现在都可以参考片段中清晰的 SQL 代码。

SELECT *
FROM users
WHERE {{ snippet: Active Users }} AND {{ snippet: Adults }}

片段对于整合和标准化您的代码至关重要。如果在任何时候您细化了活跃用户的定义，您只需更新 活跃用户 片段，更改将传播到所有使用该片段的问题。

Metabase 企业版还允许您像集合组织问题和仪表板一样，将 片段组织到文件夹中。您可以对这些文件夹设置权限，以限制对敏感 SQL 的访问，或者仅仅是为了确保用户不必翻阅与其领域无关的文件夹。

如果您发现自己编写了一个很长的片段，并且该片段返回一组结果（即，该片段不仅仅是一个 WHERE 子句——它本身就是一个查询），请考虑将该查询保存为一个问题，供其他人在其查询中引用。

已保存的问题作为构建块

对于本身就有意义的较大 SQL 代码块，请考虑将其保存为问题。毕竟，大多数人使用 Metabase 就是为了提问。

问题可以分组到仪表板中，但它们也可以作为更大查询的构建块，就像您可以在一个查询中组合多个片段一样。

假设您编写了一个查询并将其保存为一个问题。您可以将其注入到另一个查询中，如下所示：

SELECT *
FROM {{#123}}

其中 123 是问题的 ID。您还可以将该问题用作公共表表达式 (CTE)

WITH active_users AS {{#123}}
SELECT *
FROM Active Users

已保存的问题是模块化分析的一种低成本方式。通过已保存的问题模块化查询（与片段相对）的最大优势在于，您可以独立运行已保存的问题并查看其结果，这使得问题比片段更容易调试。

或者，您也可以简单地复制一个问题并基于前一个问题进行构建，但这种复制是有代价的。现在您在两个问题中拥有相同的代码；如果您后来在一个问题中发现错误，您还必须在另一个问题中纠正错误——前提是您记得它们共享相同的代码。通过简单地引用已保存的问题，您只需在一个地方更新代码。

例如，如果您是一家初创公司，您的用户数据可能分散在规范化表中。在 Metabase 中，您可以通过各种方式连接这些表，以创建用户感兴趣的问题集，从而允许他们在此基础上构建，在其自己的查询中引用这些问题以特定方式切片数据。

数据库视图

如果您认为已保存的问题与数据库中的视图非常相似，那您说对了。问题的优势在于您无需管理员权限即可创建它们，并且您可以即时创建问题并将其嵌套在其他问题中。缺点是问题是 Metabase 的构造，您将无法获得数据库原生视图的性能优化（如果有的话）。此外，当在 SQL 代码中引用另一个问题时，请记住您只能访问问题的结果：您无法访问查询本身，这意味着您无法引用其中可能存在的任何变量。

如果您发现人们经常将 Metabase 中的一个问题作为其查询的基础，请考虑与您的数据库管理员讨论创建一个物化视图，该视图返回与该已保存问题相同的结果集。物化视图的优势在于数据库无需每次都重新计算结果；物化视图的行为将非常类似于数据库中的实际表。

在 SQL 模板中使用其他已保存的问题非常适合您无法在数据库中创建视图，或者您只是在探索数据且不想创建视图的情况。

随着您的成长，将业务逻辑推向流程上游

分析的很大一部分只是以不同方式切片数据，以便更好地了解它能讲述的故事。当您找到分析立足点时，您不一定会知道哪些数据切片将帮助您为公司做出最佳决策。

随着组织分析设置的成熟，您会希望将业务逻辑推向流程上游，以便人们在 Metabase 中找到的表将您的业务逻辑单元分组在一起。策划和构建一组核心已保存问题是一种简单的方法，可以理清哪些数据对您的组织最重要。

通常，人们分析数据越容易，您的组织效率就越高。请参阅 初创公司常犯的数据模型错误 了解更多信息。