(1) 不能够带有Into关键字
我们都知道，视图其实就是一组查询语句组成。或者说，视图是封装查询语句的一个工具。在查询语句中，我们可以通过一些关键字来格式化显示的结果。如我们在平时工作中，经常会需要把某张表中的数据跟另外一张表进行合并。此时，数据库管理员就可以利用Select Into语句来完成。先把数据从某个表中查询出来，然后再添加到某个表中。当经常需要类似的操作时，我们是否可以把它制作成一张视图。每次有需要的时候，只需要运行这个视图即可，而不用每次都进行重新书写SQL代码。不过可惜的是，结果是否定的。在SQL Server数据库的视图中，是不能够带有Into关键字。如果要实现类似的功能，只有通过函数或者过程来实现。
(2) 不能使用order by排序语句
另外，跟Oracle数据库不同的是，在微软的SQLServer数据库中创建视图的时候，还有一个额外的限制。就是不能够在创建视图的查询语句中，使用order by排序语句。这是一个很特殊的规定。一些Oracle的数据库管理员，在使用SQL Server数据库创建视图的时候，经常会犯类似的错误。他们就搞不明白，为什么Oracle数据库中可行，但是在微软的数据库中则行不通呢?这恐怕只有微软数据库产品的设计者才能够回答的问题。总之我们要记住的就是，在SQLServer数据库中，建立视图时，查询语句中不能够包含Order By语句。
(3) 要对某些列取别名，并保证列名的唯一。
在表关联查询的时候，当不同表的列名相同时，只需要加上表的前缀即可。不需要对列另外进行命名。但是，在创建视图时就会出现问题，数据库会提示“duplicate column ">name”的错误提示，警告用户有重复的列名。8630.html">有时候，用户利用Select语句连接多个来自不同表的列，若拥有相同的名字，则这个语句仍然可以执行。但是，若把它复制到创建视图的窗口，创建视图时，就会不成功。查询语句跟创建视图的查询语句还有很多类似的差异。如有时候，我们在查询语句中，可能会比较频繁的采用一些算术表达式;或者在查询语句中使用函数等等。在查询的时候，我们可以不给这个列“取名”。数据库在查询的时候，会自动给其命名。但是，在创建视图时，数据库系统就会给你出难题。系统会提醒你为列取别名。从以上两个例子中，我们可以看出，虽然视图是对SQL语句的封装，但是，两者仍然有差异。创建视图的查询语句必须要遵守一定的限制。如要保证视图的各个列名的唯一;如果自阿视图中某一列是一个算术表达式、函数或者常数的时候，要给其取名字，等等。
(4) 权限上的双重限制
为了保障基础表数据的安全性，在视图创建的时候，其权限控制比较严格。
(4.1)若用户需要创建视图，则必须要有数据库视图创建的权限。这是视图建立时必须遵循的一个基本条件。如有些数据库管理员虽然具有表的创建、修改权限;但是，这并不表示这个数据库管理员就有建立视图的权限。恰恰相反，在大型数据库设计中，往往会对数据库管理员进行分工。建立基础表的就只管建立基础表;负责创建视图的就只有创建视图的权限。
(4.2)在具有创建视图权限的同时，用户还必须具有访问对应表的权限。如某个数据库管理员，已经有了创建视图的权限。此时，若其需要创建一张员工工资信息的视图，还不一定会成功。这还要这个数据库管理员有美誉跟工资信息相关的基础表的访问权限。如建立员工工资信息这张视图一共涉及到五张表，则这个数据库管理员就需要拥有者每张表的查询权限。若没有的话，则建立这张视图就会以失败告终。(4.3)就是视图权限的继承问题。如上面的例子中，这个数据库管理员不是基础表的所有者。但是经过所有者的授权，他就可以对这个基础表进行访问，就可以以此为基础建立视图。但是，这个数据库管理员有没有把对这个基础表的访问权限再授权给其他人呢?如他能否授权给A用户访问员工考勤信息表呢?答案是不一定。默认情况下，数据库管理员不能够再对其他用户进行授权。但是，若基础表的所有者，把这个权利给了数据库管理员之后，则他就可以对用户进行重新授权。让数据库管理员可以给A用户进行授权，让其可以进行相关的操作
小結:可见，视图虽然灵活，安全，方便，但是其仍然有比较多的限制条件。根据笔者的经验，一般在报表、表单等等工作上，采用视图会更加的合理。因为其SQL语句可以重复使用。而在基础表更新上，包括纪录的更改、删除或者插入上，往往是直接对基础表进行更新。对于一些表的约束，可以通过触发器、规则等等来实现;甚至可以通过前台SQL语句直接实现约束。作为数据库管理员，要有这个能力，能够判断在什么时候使用视图，什么时候直接调用基础表。