MSDN中推荐的实现行级权限的做法是这样的： * 创建表，添加用于存储用户名（或登录名）的附加列。 * 基于用户名列创建一个具有 WHERE 子句的视图。 这会将返回行限制为具有指定值的行。
' Returns the login identification name of the user.
WHERE UserName = SUSER_SNAME()
' USER_NAME or CURRENT_USER Return the database user name.
WHERE UserName = CURRENT_USER() * 基于视图而不是基表创建用于选择、插入、更新和删除数据的存储过程。 视图提供筛选器，它可限制返回或修改的行。 * 对于插入数据的存储过程，使用视图的 WHERE 子句中指定的同一函数捕获用户名并将该值插入 UserName 列。 * 拒绝 public 角色对表和视图的所有权限。 用户将不能从其他数据库角色继承权限，因为 WHERE 子句基于用户名或登录名而不基于角色。 * 为数据库角色授予对存储过程的 EXECUTE 权限。 用户只能通过提供的存储过程访问数据。
我的疑问是：1. 不明白采用视图的必要性，我的意思是完全可以基于表创建操作数据的存储过程，然后在存储过程中根据SUSER_SNAME()函数来筛选数据，同样可以实现行级的数据隔离，但官方文档中却明确指出要基于视图而不是基于表创建存储过程，为什么中间非要夹一层视图结构呢？2. 为什么要拒绝 public 角色对表和视图的所有权限？我的意思是建立一个角色只授予对存储过程的EXECUTE权限应该就足够了吧？？
对数据库的了解还不够深入，欢迎各位数据库高手们批评指正，谢谢！
' Returns the login identification name of the user.
WHERE UserName = SUSER_SNAME()
' USER_NAME or CURRENT_USER Return the database user name.
WHERE UserName = CURRENT_USER() * 基于视图而不是基表创建用于选择、插入、更新和删除数据的存储过程。 视图提供筛选器，它可限制返回或修改的行。 * 对于插入数据的存储过程，使用视图的 WHERE 子句中指定的同一函数捕获用户名并将该值插入 UserName 列。 * 拒绝 public 角色对表和视图的所有权限。 用户将不能从其他数据库角色继承权限，因为 WHERE 子句基于用户名或登录名而不基于角色。 * 为数据库角色授予对存储过程的 EXECUTE 权限。 用户只能通过提供的存储过程访问数据。
我的疑问是：1. 不明白采用视图的必要性，我的意思是完全可以基于表创建操作数据的存储过程，然后在存储过程中根据SUSER_SNAME()函数来筛选数据，同样可以实现行级的数据隔离，但官方文档中却明确指出要基于视图而不是基于表创建存储过程，为什么中间非要夹一层视图结构呢？2. 为什么要拒绝 public 角色对表和视图的所有权限？我的意思是建立一个角色只授予对存储过程的EXECUTE权限应该就足够了吧？？
对数据库的了解还不够深入，欢迎各位数据库高手们批评指正，谢谢！
我试的回答一下！~~ 如果错了 请包涵！使用视图作为安全机制
通过限制可由用户使用的数据，可以将视图作为安全机制。用户可以访问某些数据，进行查询和修改，但是表或数据库的其余部分是不可见的，也不能进行访问。无论在基础表（一个或多个）上的权限集合有多大，都必须授予、拒绝或废除访问视图中数据子集的权限。你的第一个问题！~~
存储过程 不直接在基表上！而是在视图上！
通过视图用户只能查询和修改他们所能见到的数据。数据库中的其他数据则既看不见也取不到。数据库授权命令可以使每个用户对数据库的检索限制到特定的数据库对象上，但不能授权到数据库特定行和特定的列上。通过视图，用户可以被限制在数据的不同子集上。 第二个问题public 的权限问题！~~
这是sql 权限分级中的最低的一层！~~
也就是定制的 权限级别！
--------就和法律一样！ 如果你是立法者！ 你也可以定义级别！总之
一般来说，将视图集成到查询中是比较好的，因此要求限制在视图的定义查询中避免使用group by 等等的分组类型操作，如果有了这样的操作那么视图就不能集成到主查询中！
在有些情况下， 却又要强制视图独立，也就是说先获取视图的结果集在那时会有益处！个人认为 视图是用来 查询 增加安全性的 存储过程是用来 减少重复工作量的