我们的项目里的查询显示大部分用的是数据库视图,因为各表之间有联系,想问一下这样用这么多视图好吗?
视图具有如下的一些优点:
● 简单性。视图不仅可以简化用户对数据的理解,也可以简化他们的操作。那些被经常使用的查询可以被定义为视图,从而使用户不必为以后的操作每次都指定全部的条件。
● 安全性。通过视图用户只能查询和修改他们所能见到的数据。数据库中的其他数据则既看不见也取不到。数据库授权命令可以使每个用户对数据库的检索限制到特定的数据库对象上,但不能授权到数据库特定行和特定的列上。通过视图,用户可以被限制在数据的不同子集上。
● 逻辑数据独立性。视图可以使应用程序和数据库表在一定程度上独立。如果没有视图,应用一定是建立在表上的。有了视图之后,程序可以建立在视图之上,从而程序与数据库表被视图分割开来。
视图也存在一些缺点,主要如下。
● 性能:SQL Server必须把视图的查询转化成对基本表的查询,如果这个视图是由一个复杂的多表查询所定义,那么,即使是视图的一个简单查询,SQL Server也把它变成一个复杂的结合体,需要花费一定的时间。
● 修改限制:当用户试图修改视图的某些行时,SQL Server必须把它转化为对基本表的某些行的修改。对于简单视图来说,这是很方便的,但是,对于比较复杂的视图,可能是不可修改的。
所以,在定义数据库对象时,不能不加选择地来定义视图,应该权衡视图的优点和缺点,合理地定义视图。
怎么说呢? 个人觉得都是习惯的问题啊,有人喜欢inner join 有人喜欢用视图,没有固定的要求
那是用inner join好一些还是用视图好一些呢
@淘@淘: 可以自己测试一下,我觉得没有什么区别的
不喜欢用视图,我们的项目没用任何数据库视图
视图的话,到时要换数据库就会成为一个麻烦,比如从SQL转到access这种,如果不会更改数据训的话那就没问题
估计数据库是不会换的,以前没用过视图,这次用了这么多视图心里感觉没底,不知道好不好