开发中何时使用数据库视图？

Question

学习数据库的时候基本绕不开视图，但是在实际的开发中，我基本没遇到过使用视图的项目，基本都是ORM框架直接对数据库进行操作？
现实中到底什么场景下需要使用视图呢？

Answer 1

首先用 ORM 和用视图又不冲突，你在 ORM 里把视图当作普通的表一样去读不就好了？

其次视图本质就是帮你在一堆表里 JOIN 之后生成一个结果集 R，后面的查询都在这个 R 上做就可以了，省得每次查询前还得重新 JOIN 一遍。就这么一个优势。

还是那句话，抛开场景谈架构都是耍流氓。之所以你感觉数据库视图用的少，那是因为近年来随着互联网产业的兴起，大部分技术面经也好、案例交流也罢、甚至包括各种开源生态，不能说全都是、但可以说几乎都是针对互联网服务这一场景服务的。

互联网服务的数据库一般有什么特点？读多写少、海量数据、高频访问……

这些特定都决定了这类场景下就尽量不要 JOIN 才好，甚至像有些规范里明确规定禁止三表以上 JOIN 了。所以视图这种“对外黑箱、难以优化”的玩意儿自然就很少用到了。

而且不光是视图，像什么存储过程啊、触发器啊、数据库事务啊，这些传统软件开发里司空见惯的玩意儿，在互联网这种特殊场景下反而变得鸡肋了起来。

---

但事实上如果你的项目业务复杂度没那么高、数据量没那么大，有些时候用视图其实挺省心的。

可以分享一个我公司的案例：

我们有一个大系统下子系统，其中有一项业务是需要把某些数据同步给第三方。说是第三方，其实是另一个大部门的开发团队，跟我们互不统属（你可以近似理解为我们是做对外的产品业务的，他们是做内部的 OA 系统的）。这项业务需要访问来自大概十多张表的数据，但这些表里有某些列比较敏感、而且他们也不需要。这个时候视图就派上用场了，我们只开放了一个只能访问这张视图的数据库账号，提供给对方让对方读就好了，这样完全屏蔽了背后的那十多张表的细节 —— 对我们来说省心，权限容易控制了；对对方来说也省心，毕竟不是自己的业务，也不用去关心这十多张表里的数据到底应该怎么 JOIN 的。

你说不用数据库视图、难道就满足不了这个业务需求、解决不了前面的问题吗？那显然是扯淡。但这里用视图虽然不是特别完美的解决方案、但一定是最简单的那一种。

Answer 2

这个问题，我觉得可以去系统的看一下数据库的教程，也可以上网查一下视图的作用和优缺点。我认为视图基本上可以看作就是一个缓存的查询结果（可以更新），可能会存在一些性能上有缺陷，比如对于较大量的数据来说，在联表后查询（视图方式）和在过滤后（少量数据）联表相比，可能后者效率更优，而后者是不能用视图实现的

数据库不是我强项，仅供参考。建议多查查资料，参考印证。

Answer 3

PostgreSQL 视图

对视图的使用是成就一个好的SQL数据库设计的关键方面。视图允许用户通过始终如一的接口封装表的结构细节，这样可以避免表结构随着应用的进化而改变。