以下内容主要针对database层面的数据访问权限（比如select, insert, update, delete, execute…）
1.直接给user权限
GRANT EXECUTE TO [user]
2.通过role 控制权限，把user加入role中，继承Role所拥有的权限
GRANT EXECUTE TO [Role]
ALTER ROLE [Role] ADD MEMBER [Member]
3.通过app role的方式访问数据库
Application Role 是数据库级别的Role，不包含任何user，不能直接在数据库中使用，只能通过应用程序连接数据库使用。
Application Role不能和前面两种方式同时生效，如果某个login已经有数据库对应的User，而且赋予了相应的权限，但登录以后又激活了Application Role，那么这个login的security context就会切换到Application Role的security context，也就是只有Application Role的权限起作用。
需要注意的是在应用程序中激活了Application role之后，要访问其他的数据库只能用Guest account，鉴于Guest account被很多DBA视为眼中钉肉中刺，想用Application Role的还是请三思。
4.Sp 的 execute as XX
这是一种较为推荐的方式，可以在最小的粒度上控制权限。
这种方法就像领了尚方宝剑，比如 A是sp1的owner，sp1定义为 execute as owner，然后B有sp1的执行权限，那么B执行sp1的时候就拥有了A的所有权限，有效期到sp1执行结束。
类似的用法还有execute as caller/self/”username”/”loginName”. 默认情况，如果sp不写execute as 语句，用的是execute as caller.
5.Owned schema
Schema作为数据库中对象的集合，也可以用来控制权限，通过给用户赋予schema的权限，就同时赋予了schema包含的所有table，view，sp的权限。
可以在赋予schema权限之后，再在对象级别(table，view…)修改访问权限，最终以对象级别的权限为优先。