[转]Sql Server 2005中的架构(Schema)、用户(User)、登录(Login)和角色(Role)

每一个概念的产生必然是因为碰到了无法解决的问题。换句话说，如果没有它，必然会导致某些问题难以解决。所以我想从这个角度切入，希望能把这几个复杂而暧昧的多角关系从最实用的角度来阐述清楚。

在问题的最初，我们假定的数据库什么都没有。数据库对象。首先,数据库对象是比较容易懂的。所有的表,视图，存储过程，触发器都称为数据库对象。

我们可以拿一个网站来做类比。一个网站包含很多的网页，图片，脚本文件，我们姑且称它为网站对象。显然，我们不可能把所有的网站对象都放到一个文件夹下面，同样道理，数据库对象也不可能象煮饺子一样就在数据库里这么一锅出。对于网站，我们通常会把不同模块的文件放在不同的子文件夹下，那么谁是存放数据库对象的文件夹呢？答案就是：架构（Schema）.

架构（Schema）。微软的官方说明（MSDN）： "数据库架构是一个独立于数据库用户的非重复命名空间，您可以将架构视为对象的容器"，详细参考http://technet.microsoft.com/zh-cn/library/ms190387.aspx.我们知道，在JAVA中，命名空间名其实就是文件夹名。因此我们非常明确一点：一个对象只能属于一个架构，就像一个文件只能存放于一个文件夹中一样。与文件夹不同的是，架构是不能嵌套的，如此而已。因此，我们要访问一个数据库对象的时候，通常应该是引用它的全名"架构名. 对象名"，这点非常类似C#。

问：为什么有的时候写select * from tablename也可以执行呢？

答:这是因为default schema.当只写tablename时，Sql Server会自动加上当前登录用户的default schema。

如果此表不属于当前登录用户的default schema,将会提示无效的对象名。

加上shcema以后成功。

不过我们也可以更改当前用户的default schema，这时就可以不用加前缀了。

ALTER USER dbo WITH DEFAULT_SCHEMA =emdbuser;

当然，我们也可以改变此表的schema,相当于把这个表放到另一个文件夹,从emdbuser放到dbo中。

alter schema dbo TRANSFER emdbuser.Borrower

以上两种作法在真实项目中都不应该作为解决方案，因为它改变了原来的设置。我们最希望的是，即使我们以dbo登陆，我们也可以伪装成emdbuser来操作数据库对象，伪装完了还能切换回来。在Sql Server中,刚好有这样的语句实现这个功能。

EXECUTE AS USER = 'emdbuser';

这种机制被称为“上下文切换”，操作完以后，可以实用REVERT命令切换回来。（.NET中也有类似的机制,它们有共同的一个名称叫做Impersonate，角色扮演。）

详细解释参照MSDN http://msdn.microsoft.com/zh-cn/library/bb153640(SQL.90).aspx

问：如何根据表名获取一个表的Schema呢？

答：可以参照以下SQL语句从sys.objects视图和sys.schemas视图中获取。

select sys.objects.name,
　　　sys.schemas.name
 from sys.objects,
　　sys.schemas
where sys.objects.type='U'
　　and　 sys.objects.schema_id=sys.schemas.schema_id

结论：架构就是数据库对象的容器。数据库对象是饮料，架构就是杯子，谁拿杯子喝水呢？当然是用户，那么是不是一个用户只能用一个杯子，一个杯子是不是从一而终，只能给一个人用呢？

---

我们暂时忘记架构这个东西。我们假设我们的数据库只有数据库对象。

李老板开了一个小公司，公司有个仓库，堆放了一些货物，由于仓库小，为了节约成本，这个仓库根本没有锁。只要知道仓库在哪里，就可以去取货。这种情况对应数据库来说，就是只要我知道数据库名和表名，我就可以对它进行操作。这对程序员来说当然是最方便了。这就是数据库的第一阶段：无权限管理阶段。假如大家用过Win3.X,那它们基本就是无权限管理阶段。这下小偷就爽翻了。

最近仓库里的东西老是不翼而飞。李老板才明白，就算是员工都是自觉的，但是别的人也可以拿走里面的货物，怎么办呢？老板一咬牙，花一百块钱买了一把锁！并且只给少数几个人配钥匙。这下东西被别的公司的人拿走的情况基本杜绝了。对于数据库来说，相当于把人分成了两种，一种授权用户，一种未授权用户。这时，数据库就有了用户的概念，但是它只有一个用户，就是有钥匙的人，它只对有钥匙的人开放。这就是数据库权限管理的第二阶段：上锁阶段或者单用户管理阶段。好景不长，老板发现仓库的东西还是经常少。明明都是有钥匙的人才能进去呀。但是，谁拿了多少，根本没办法查出来。老板猜测原因有二：一，有些人拿了不该拿的东西。二，有些人偷偷的去配了钥匙。老板一咬牙，没收所有的钥匙。花800块一个月雇个仓库管理员，每个进仓库拿东西的人都要登记。李老板还给给仓库管理员一个清单，谁可以拿什么东西，清单如下：

姓名	货物0	货物1	货物2	货物3	货物4
A	Y	Y	N	N	N
B	Y	Y	Y	N	N
C	Y	Y	Y	Y	Y
D	N	Y	Y	Y	Y

也许有人细心的发现，你说的不对，windows权限管理中有角色呀！没错，为什么要有角色呢？没有角色不是照样不丢东西吗？这个问题稍后再谈。

话说过了一年，李老板的生意越做越大，仓库里的东西也越来越多，最近A反应，去仓库取货老是要排队，而且经常要等很久才能取到货，李老板心想，取货的人一共就这几个人，还要排队，岂有此理！把仓库保管员叫过来！保管员早有准备，递给李老板一份最新的清单：

姓名	货物0	货物1	货物2	货物…	货物1000
A	Y	Y	N		N
B	Y	Y	Y		N
C	Y	Y	Y		Y
D	N	Y	Y		Y

每次来一个人取货，保管员都要根据这张清单对一千个货物，幸亏取货的人少，如果再多几个人的话，估计就要在仓库门口打架了。李老板又开始琢磨了。现在东西是不会丢了，但是每次取货慢成这样，等我货再多到一万种，我这生意还能做吗？该怎么才能提高仓库管理员的效率呢？这时仓库管理员早看出李老板的心思，色咪咪看着李老板着说:“老板，再招一个管理员吧，我老婆刚好生完孩子在家里待业。。。”。李老板一听就火了：你当招人不用花钱啊！有了！我买5个货架就搞定了！过两天我告诉你新的管理办法，你老婆还是在家多休息几天吧。

过了几天，老板把5个货架采购回来，放进仓库，然后给管理员一份管理手册。新的管理手册如下：

每次货物入库的时候，根据货架货物清单放到相应的货架上，然后贴上标签。出库的时候只要看货架号码就可以啦。

看到这里，也许有人恍然大悟，这不就是第一节讲的“架构Schema”吗？没错，现在我们终于知道，架构概念的引入就是为了解决数据库对象太多不好管理的缺点。到现在为止，我们的数据库管理就变成了用户-架构-数据库对象的模式了。

在sql server2000中，用户和架构是不分离的，到了2005才分离。其实2000中的用户和架构概念就是给张三、李四分配固定的货架。这是一种更简单的管理方法。