跳转到主要内容
模块 9 · 第 4 课(共 4)课程中的36/57~12 min
模块课程(4/4)

视图和数据抽象

在我们的课程中,您会注意到查询(特别是复杂的 JOIN 或像 GROUP BY 这样的聚合)开始变得很长并且充满了规则和计算。

如果有一种方法可以在心里保存已完成的查询并将其隐藏在视图中,从那时起就假装它是数据库的普通“表”?

欢迎来到视图的世界。

创建视图

视图本质上是一个持久的、命名的 SQL 查询,但它的行为就像一个“虚拟”表!

SQL
CREATE VIEW user_spending AS
SELECT
  c.id,
  c.first_name,
  SUM(o.amount) as total_spent
FROM customers c
JOIN orders o ON c.id = o.customer_id
GROUP BY c.id;

完毕!现在,您不必总是重做 JOIN 和 GROUP BY,而只需编写完美的正常查询:

SQL
SELECT * FROM user_spending WHERE total_spent > 100;
-- Postgres dietro le quinte richiamerà automaticamente la grande formula.

视图和“实时数据”

一个非常常见的神话是认为Views获取数据,计算价格或排名之类的总和,并生成一些悲伤的持久快照,例如照片。 错误(几乎总是)!默认情况下,视图是虚拟的:每次您将视图名称放入 SELECT 中时,Postgres 都会在后台根据数据库在该毫秒的状态运行实时计算来合并您的请求。所以你永远不会读取过时的数据。

它们是做什么用的?

  • 简单:视图保护外部应用程序免受更改。如果前端团队知道它必须从 top_selling 视图中读取数据,他们就不必担心明天我们是否通过添加三个中间关系来修改数据库来拉出最畅销的商品!
  • 安全和隔离:在巨大的数据库中,视图可以预先选择并向外部开发人员隐藏部分用户数据,仅授予他们访问(例如)删除真实姓名的分析子视图的权限。

删除视图

就像表一样,当不再需要时,您可以继续使用 DROP 命令:

SQL
DROP VIEW user_spending;

尝试一下

锻炼#sql.m9.l4.e1
尝试:0加载中...

创建一个名为“high_value_products”的视图 (VIEW)。它必须充当一个容器,从“产品”表中选择所有 3 个基本字段(“id”、“名称”、“价格”),但仅且始终适用于“价格”大于 50.00 的产品。

正在加载编辑器...
显示提示

写入 CREATE VIEW view_name AS SELECT ... FROM ... WHERE ...

3 次尝试后可用的解决方案

调用视图

锻炼#sql.m9.l4.e2
尝试:0加载中...

由于平台上的每个练习都是在隔离(且干净)的环境中运行的,因此在此步骤中不再存在先前的视图。重新创建“high_value_products”视图(仍包含价格 > 50 的产品),然后在紧随其后的行中,按价格降序 (DESC) 对其所有内容运行 SELECT 以验证其是否有效。

正在加载编辑器...
显示提示

不要忘记 ; SQL语句之间(放在第一行末尾)!这让 Postgres 按顺序执行 2 个任务。

3 次尝试后可用的解决方案