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 数据库设计与角色