前一阵子某市的健康码崩溃的事情又让吃瓜群众们兴奋了一把，一时间各种爬电线杆找信号的图片在网上快速传播。然后据说有技术人员看了代码之后，表示该健康码后台用了一个有N个字段的超大视图。

不了解 数据库技术 的朋友可能不太了解视图是啥东西。视图是指计算机数据库中的视图，是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。

说白了，就是一个公司有好几个部门，每个员工的实际信息都物理存在部门里面。而这时候要搞一个公司的篮球兴趣小组，把身高超过180厘米的男生都选出来，那么这个篮球小组就类似一个视图。即人员还是属于部门的，但具有某些属性的人员单独提出来，变成了一个虚拟的小组。这个就是视图。

视图是被各大数据库如 Oracle 、 Postgresql 、 MySql 等都支持的一个基础功能，但是长期以来，大多数互联网公司的《 MySQL 开发规范》中都有一条规范：在MySQL中禁止（或建议不要）使用视图。

那么这是为什么呢？制订这条规则的时候，主要是由于在MySQL中视图的查询性能不好，同时带来了管理维护上的高成本。

但是，随着MySql新版本的发布，视图的查询性能有了较大的增长。这时候，就有某些 程序员 跳出来，说这条规范应该改了，已经过时了，我们应该可以使用视图了。

那么，到底应该不应该使用视图呢？显而易见，在不使用视图的情况下，互联网公司的平台运行得好好的。也就是说不用视图功能对功能并没有什么影响，甚至有些小公司的程序员，虽然从来没听说过这条规范，但是在实际的使用中，他们也从来没有碰上过非用视图不可的场景。

那么为什么会这样呢？我们先来看看视图的本质是什么？其实视图的本质作用就一点：固化了一部分业务逻辑。至于什么隐藏几个字段不被用户发现什么的，并不重要，很多方法都能实现。

在数据库早期的发展阶段，数据可视化功能很弱，很多东西都还需要命令行操作。因此，把一部分业务逻辑固定在视图里，是可以理解的。

而目前信息系统已经完全脱离命令行操作的阶段，而更多的是使用类似于Java EE的三层架构来实现。在这些信息系统里，业务逻辑已经固化在了业务逻辑层。因此，完全不需要使用视图来固化这部分业务逻辑。至于视图的其它一些优点，在信息系统数据可视化界面上非常容易实现。

因此，可以说 视图的主要需求场景，在当前的时代已经极度弱化。这一功能也就成了鸡肋。所以大部分系统里面没有视图的出现，也就是可以理解的事情了。

所以说，《MySQL开发规范》关于禁止使用视图的规定并没有过时，而视图本身，已经过时了。

喜欢本文的话，欢迎关注 活在信息时代 哦：）