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

摘要：【目的】了解数据库中角色（Role）的概念和用处。【方法】用李老板的公司发展中碰到的问题例证角色的重要性【结论】角色在用户越多的情况下越能凸显出它的作用。

3.1 深入了解架构(Schema)
在进入李老板的故事之前，让我们先对Sql Server2005中的架构做一个更深入的了解。
用户(User)和架构(Schema)的关系

一个架构有且只有一个所有者Owner。

一个用户可以拥有多个架构。

这跟第二节中介绍的货架权限清单有所出入，第二节中的例子是多对多的关系，而实际Sql Server是采用一对多的关系。这反而比较像是银行账户。一个人可以有多个存折，但是一个存折只有一个用户。

创建一个用户，系统将自动创建一个同名的架构。

创建一个架构必须指定所有者，否则将默认为当前登陆用户。

表属于不同的架构也不能重名。

删除一个用户时，架构也会被删除？

架构(Schema)相关的SQL

创建架构

CREATE SCHEMA [SchemaName] AUTHORIZATION [User]

更改架构的所有者

删除架构

数据库设计与架构

架构的目的应该在于在同一数据库中提供一种隔离机制。按照这种思路，以最典型的产供销结构，我们可以这样设计一个数据库MyDatabase：

用户	架构	表	表全称
生产者	生产	表1	生产.表1
供应者	供应	表2	供应.表2
销售者	销售	表3	销售.表3

这样生产者登陆以后只能操作表1，供应者登陆以后只能操作表2...隔离效果非常好。但是，如果总经理想要查看一个产供销的综合报表该如何办呢？在这样的设计下，是根本做不到的。所以我们目前看到的实际情况是，基本上一个数据库只用一个架构和一个用户登陆。

用户	架构	表	表全称
MyUser	MySchema	表1	MySchema.表1
		表2	MySchema.表2
		表3	MySchema.表3

这下总经理要看报表是没问题了，但是这样架构就形同虚设了。这也是为什么大家搞不清楚架构和用户的关系的原因。假如一个架构可以有多个拥有者，那么就可以彻底解决这个问题。

有人要说了，但是好像我用dbo登陆以后，是可以操作不同架构的表啊，这是为什么呢？那是因为上面的讨论是建立在没有角色的基础上的，要说清楚角色的问题，我们还是要回到李老板的故事。

3.2 人多不好管
1.大量的重复

2.工作调动

3.3 所有权与经营权
3.4 DB Role与App Role
3.5 数据库设计与角色