SQL - 1.区分login、user、schema和role

 

  Login

Login 是Server一级的概念，表示登录Server的凭证，比如在Server_A上有一个数据库DA,那么想要访问数据库DA，第一步要做的事情就是先登录到Hosting该数据库的Server_A上，数据库管理员可以用下面的T-SQL语句来创建一个Login，暂且命名为ReportLogin。

• Windows Authentication:

Create login [ReportLogin] from windows with default_database = [master],default_language = [us_english]

• SQL Server Authentication:

Create login [ReportLogin] with password = 'abc***123456abc',default_database = [master],default_language = [us_english]

按照上面的语句创建 SQL Server验证的[ReportLogin]为强制密码策略，默认数据库为master，默认语言为英语，Server roles为public，user mapping中为默认的public，securables为当前服务器，权限设设置为可以连接SQL并查看Any Database，赋予它连接数据库权限的是sa.

安装完数据库软件后，会有一些预创建的Login，比较著名的就是sa和BuildIn/Administrators。

user

有了一个Login，表明你可以登录hosting该Database的Server，并不表明你能够访问数据库，除非你是内置的Windows管理员，否则，你只能登录到该Server上，什么事情都做不了，就好比，你有了一个私家小院的大门钥匙（Login），你打开大门（登录），你只能在院子里边站着，因为房间的门都是锁着的，你没有房间的钥匙（User）啊，怎样才能进到屋子里边去呢？User就是要完成这样的功能。我们可以用下边的T-SQL语句来创建一个User，暂且命名为ReportUser，由于User属于数据库对象，不属于Server对象（Login属于Server对象），因此我们如果想创建一个User，首先必须进入到想创建User的数据库中（use 该数据库），然后创建User。

create user [ReportUser] for login [ReportLogin] with default_schema = ReportSchema

go
   注：最后面的default_schema是指定服务器为此数据库用户解析对象名时将搜索的第一个架构。 
    通过语句我们可以看出来，每一个User都要映射到一个Login，所以这里的关系就是：

·         每个User必须对应一个Login。

·         每个Login可以对应多个User，前提是User在不同的数据库中。

一旦我们创建了映射到某个Login的User，那么此时，如果我们用该Login登录，就可以访问拥有该User的数据库了，继续打比方，我们用Login打开了大门，我们进入了小院子，此时我们还有一个User，就表明我们手上还有某个房间门的钥匙，那么此时我们可以打开房间门（数据库），堂而皇之地进入到这个小房间了。

安装完数据库软件后，会有一些预创建的User，比较著名的就是dbo,guest,sys等等。

Schema

九牛二虎之力之后，我们终于如愿以偿地进入到我们的房间了，却发现原来里边都是上下铺，究竟那个床（Schema）才是我的呢？我能把我的行李放在哪里呢？这个就是架构，Schema：数据库数据库架构是一个独立于数据库用户的非重复命名空间，您可以将架构视为对象的容器，这不就是床了，放东西啦。相信容器的概念大家已经很熟悉了，比如一块新硬盘，我们会为他划分为N个盘符，C:,D:,E:啊之类的，在每个盘符之下，我们又有N个文件夹Folder，这些都是容器。再比如我们可以拿一个网站来做类比，一个网站包含很多的网页，图片，脚本文件，我们姑且称它为网站对象。显然，我们不可能把所有的网站对象都放到一个文件夹下面，同样道理，数据库对象也不可能象煮饺子一样就在数据库里这么一锅出。对于网站，我们通常会把不同模块的文件放在不同的子文件夹下，那么谁是存放数据库对象的文件夹呢？答案就是：架构（Schema）。

实际上数据库的每个对象都是有架构的，既每个数据库对象都有放的位置，但是我们很多人在创建数据库对象的时候却没有指定。在SQL Server 2005之后的版本中，当我们创建数据库对象没有显式指定Schema时，数据库会为我们默认地指定一个默认Schema: dbo。所有没有显式指定Schema的数据库对象，统统地被放在了dbo这个公共空间中。

架构（Schema）概念的引入就是为了解决数据库对象太多不好管理的缺点。

安装完数据库软件后，会有一些预创建的Schema，包括dbo,以及每个以预定义Role命名的Schema，比如： db_owner,db_datareader,db_datawriter

等等。

Role

角色这个概念是为了降低管理成本，简化管理的工作量而出现的，试想如果一个公司有1000人，每个人都需要对某个表进行write的权限，如果没有角色，我们要对这1000个人分别Grant权限，就是单单copy运行，也需要很久啊，如果公司有3000人呢？估计管理员早就不干了。角色（Role）就是为了解决这个问题而出现的。建立一个角色（Role），数据库管理员只用Grant这个角色拥有对这个个表的write权限就OK了，下一步要做的工作就是把公司里边需要对这个表具有write权限的员工赋予这个Role即可，管理成本是不是降低了不少(就是将一批需要的权限放在一个Role里面，并将这个Role授权给一批user)。

安装完数据库软件后，会有一些预创建的Server Role和Database Role（以db_开头）。

Server Roles:

1.       bulkadmin

2.       dbcreator

3.       diskadmin

4.       processadmin

5.       public               ---- 每个新建login的默认Server Role

6.       securityadmin

7.       serveradmin

8.       setupadmin

9.       sysadmin

Database Roles:

1.       db_accessadmin

2.       db_backupopeator

3.       db_datareader

4.       db_datawriter

5.       db_ddladmin

6.       db_denydatareader

7.       db_denydatawriter

8.       db_owner

9.       db_securityadmin

10.   public

至于具体每个角色的权限有多大，究竟每个角色能做什么事情，请查看Book Online，微软的idea是数据库所预装的Role能完成大部分的权限分配问题。