对比视图和存储过程的使用和学习体会进行选择。

在这几天应用和学习的过程中，总结下这2个应用比较多的数据库封装方式。

1.视图主要是针对select的动作，同时他不能做逻辑判断处理，因为视图的作用在于方便做出查询，为了安全性，把多个表通过视图的组合把查询结果返回给用户。

2.我在作不同角色用户查询信息初期，考虑过用视图来针对不同用户返回不同的信息。

3.就是简化了很多用户的操作，我使用视图或者存储过程的原因就是为了让上层的代码简化些，有变动的话直接改动视图和存储过程的内容。

但是这点在我交流过程中有异议，部分人认为不应该把过多的业务放在存储过程和视图中，因为首先项目的数据库会出现更换的情况下，数据库的存储过程和视图就会面临大面积修改的情况。同时也会出线数据库表分离的场景。不过这2个因素都是因为担心数据库变动让存储过程修改的比较多。

不过从我做大数据量性能测试或者处理的场景下，在我上层语言算法优化实力不是很足的情况，我使用数据库语言去处理大数据量的信息效率肯定是比我自己在后台语言处理的性能高。其二就是在我这种轻量级的web应用业务上，其实数据库改动的情况较低，即使改动，我的后台语言肯定改的工作量不会比数据库改的少。

4.这点就是数据对比，在我的使用过程中用得比较少。但是交流的时候得知有这个优点存在。

在使用过程中，也发现了一些视图的缺点：

1.就是我在做4表联合查询的时候，语句比较复杂，担心以后有改动的话会非常麻烦，假如把逻辑写在后台那边修改就很方便。

2.就是性能，因为视图它是创建了一个虚表，然后以窗口方式输出到用户方，所以性能会比直接操作查询低。

所以在使用过程中，像一些性能杀手的条件查询等，在视图内使用不要放在视图外，同时我也询问了下，尽量不要在存储过程或者视图中嵌套一层，这个方面我还没仔细研究原因。

3.还有在web的框架中会要求返回的表需要主键，所以我会在编写视图时要注意这个操作

说到存储过程，我发现我在使用中不自觉的在能用存储过程的地方尽量不要视图，原因其实很简单。

虽然说存储过程着重在于过程没有返回，但是在执行一些有逻辑算法的情况下，存储过程基本上最后是查询的情况下就是有返回的。

最重要一点就是性能，我这个数据库初哥大胆使用存储过程的原因，就是把数据从数据库中取出来的数据提高，即使我还是不太习惯数据库的存储过程语法。

所以存储过程虽然我在使用上还没做到一些语言的函数和过程那样解决语句的复用性，但是已经把很多上层代码移到数据库中执行一是简化了上层语言的代码简洁，二是上面所说道的性能。

但是有些地方还是不能用封装的，就是多个数据库查询的时候，封装明显会有些预想不到的错误，这一步将会在我下一阶段对函数，索引一起做研究。

最后总结，简单的多表查询使用视图，其他的情况下大多数使用存储过程。