关于什么是用户权限，最简单的定义可能是，“用户能做什么和不能做什么。”在这里，简单的定义就相当不错了。
用户的权限分为3类：
l 登录的权限；
l 访问特定数据库的权限；
l 在数据库中具体的对象上执行特定操作的权限。
既然我们已经看过了创建登录账户，这里将把重点放在登录账户能够拥有的特定权限上。
22.3.1 授予访问特定数据库的权限
如果想要一个用户可以访问数据库，你需要做的第一件事情是授予用户访问那个数据库的权限。可以在Management Studio中，通过把用户加入到服务器的数据库结点的用户成员中来实现。如果要用T-SQL来添加用户，需要使用CREATE USER或遗留的存储过程sp_grantdbaccess。
注意，当你在数据库中CREATE一个用户时，实际上，那些许可权限被存储在数据库中，并映射到那个用户的服务器标识符上。当还原数据库时，可能不得不在还原数据库的地方，重新把用户权限映射到服务器标识符。
1．CREATE USER
CREATE USER命令把新用户添加到数据库中。用户可以源自现有的登录名、证书或非对称密钥，用户也可以是只能在当前数据库中的本地用户。其语法如下：
CREATE USER <用户名>
[ { { FOR | FROM }
{
LOGIN <登录名>
| CERTIFICATE <证书名>
| ASYMMETRIC KEY <密钥名>
}
| WITHOUT LOGIN ]
[ WITH DEFAULT_SCHEMA = <模式名> ]
对于这些元素，我们概略看一下其中一些元素的含义是什么：
选 项
说 明
LOGIN
想要授予访问当前数据库的权限的登录名
CERTIFICATE
与用户关联的证书的逻辑名称。注意，必须已经使用CREATE CERTIFICATE命令创建了证书
ASYMMETRIC KEY
与用户关联的非对称密钥的逻辑名称。注意，必须已经使用CREATE ASYMMETRIC KEY命令创建了密钥
WITHOUT LOGIN
创建只能在当前数据库中活动的用户。可以用它来建立特定的安全上下文，但是，该用户不能映射到当前数据库之外的登录名，也不能访问任何其他的数据库
WITH DEFAULT_SCHEMA
设立不是默认的“dbo”的模式，以作为当前用户的默认模式
2．sp_grantdbaccess
这是遗留的方法，用来授予登录名到特定数据库的访问权限。其语法如下：
sp_grantdbaccess [@loginame =] <登录名>[, [@name_in_db =] <数据库中的别名>
注意，授予的是当前数据库的访问权限――即是说，你 必须确保想要用户能够访问的数据库是发出该命令时的当前数据库。登录名是用来登录到SQL Server中的实际的登录ID。参数name_in_db允许给该用户另外的识别名称。这个别名只适用于此处的数据库――其他所有的数据库仍将使用该登 录ID的默认名称，或者使用在授予用户那个数据库的访问权限时所定义的别名。定义别名将影响身份识别函数，如USER_NAME()。系统级别的函数（如 SYSTEM_USER）将返回基础的登录ID。
22.3.2 授予数据库中对象的权限
好吧，用户拥有了登录名，并且，能够访问你想要他或她可以访问的数据库，那么，是否现在就万事大吉了呢？如果事情真有那么简单就好了！现在当然还没有一切就绪。
在用户能够访问什么的问题上，SQL Server给了我们级别相当精细的控制。多数时候，一些信息是希望用户能够访问到的，但是，数据库中也有另一些信息是不希望用户访问的。例如，你可能想 要客户服务人员能够查看和维护订单信息，但是可能不希望他们乱看工资信息。或许，反之亦然――你需要人力资源人员能够编辑雇员记录，但是，或许不想要他们 在交易上给某人很大的折扣。
SQL Server允许你给SQL Server中一些不同的对象指派一组不同的权限。能够为其指派权限的对象包括表、视图和存储过程。触发器隐含具有创建它们的人的权限。
对象上的用户权限分为6种不同的类型。
用户权限
说 明
SELECT
允许用户“看到”数据。如果用户拥有该权限，则用户能够在其被授予权限的表或视图上运行SELECT语句
INSERT
允许用户创建新的数据。具有这种权限的用户能够运行INSERT语句。注意，与许多系统不同，具有INSERT能力并不一定意味着拥有SELECT权限
UPDATE
允许用户修改已有的数据。具有这种权限的用户能够运行UPDATE语句。类似于INSERT语句，具有UPDATE能力并不一定意味着拥有SELECT权限。
DELETE
允许用户删除数据。具有这种权限的用户能够运行DELETE语句。同样，具有DELETE能力不一定意味着拥有SELECT权限
REFERENCES
在要插入行的表中有引用另一个表的外键约束，而用户在那个表上没有SELECT权限，REFERENCES权限允许用户插入行
EXECUTE
允许用户EXECUTE指定的存储过程
在你正在把权限指定到其上的特定的表、视图或存储过程中，可以在需要时混合搭配这些权限。
可以在Management Studio中指派这些权限，你只需导航到服务器的“安全性”结点的“登录名”选项上。在用户上右击，并选择“属性”。根据你是在数据库中还是在安全性结 点中，打开的对话框将有所不同，但是，无论哪一种情况，都能够得到设置权限的选项。使用T-SQL指派权限会使用三个命令，了解这三个命令是有益的，即使 你只准备通过Management Studio来指派权限（术语是相同的）。
1．GRANT
GRANT把对象上指定的访问权限给予指定的用户或角色，对象是GRANT语句的主体。
GRANT语句的语法如下所示：
GRANT
ALL [PRIVILEGES] | <权限>[,...n]
ON
<表名或视图名>[(<列名>[,...n])]
|<存储过程或扩展存储过程名>
TO <登录ID或角色名>[,...n]
[WITH GRANT OPTION]
[AS <角色名>]
ALL关键字表示你想要授予的是适用于那个对象类型的所有权限（EXECUTE绝不适用于表）。如果不使用ALL关键字，则需要提供一个或多个具体的权限，这些具体的权限是针对那个对象想要授予的。
PRIVILEGES是一个新的关键字，它除了提供ANSI-92兼容性外没有实际的功能。
ON关键字用作一个占位符，以说明接下来的是想要授予其权限的对象。注意，如果你是在表上授予权限，可以通过明确说明受影响的列的列表来指定下至列级的权限――如果不提供具体的列，则认为将影响所有的列。
在对列级权限的看法 上，微软似乎做的是些表面的事情。能够说一个用户可以在特定的表上进行SELECT，但仅限于在该表中特定的列上进行SELECT，这似乎很酷，然而，在 列级权限的使用中以及微软为实现列级权限所做的工作中，确实让安全性处理太过错综复杂了。鉴于此，近来关于该主题的文献，以及我从内部人士那里得到的消 息，似乎都表明微软想要丢弃列级安全性了。在使用上他们建议――如果需要限制用户只能看到特定的列，请改为考虑使用视图。
TO语句所做的事情正如你期望的那样――它指定想要把该访问权限授予谁。被授予权限的可以是登录ID或角色名。
WITH GRANT OPTION允许你向其授予访问权限的用户也能向其他用户授予访问权限。
由于使用该选项 后，要了解谁获得了访问什么的权限，将很快变得十分痛苦，因此，我建议避免使用该选项。当然，你总是可以进入到Management Studio中来查看