3.1 深入了解架构(Schema)
在进入李老板的故事之前,让我们先对Sql Server2005中的架构做一个更深入的了解。
用户(User)和架构(Schema)的关系
- 一个架构有且只有一个所有者Owner。
- 一个用户可以拥有多个架构。
这跟第二节中介绍的货架权限清单有所出入,第二节中的例子是多对多的关系,而实际Sql Server是采用一对多的关系。这反而比较像是银行账户。一个人可以有多个存折,但是一个存折只有一个用户。
- 创建一个用户,系统将自动创建一个同名的架构。
- 创建一个架构必须指定所有者,否则将默认为当前登陆用户。
- 表属于不同的架构也不能重名。
- 删除一个用户时,架构也会被删除?
架构(Schema)相关的SQL
创建架构
CREATE SCHEMA [SchemaName] AUTHORIZATION [User]
更改架构的所有者
删除架构
数据库设计与架构
架构的目的应该在于在同一数据库中提供一种隔离机制。按照这种思路,以最典型的产供销结构,我们可以这样设计一个数据库MyDatabase:
用户 | 架构 | 表 | 表全称 |
生产者 | 生产 | 表1 | 生产.表1 |
供应者 | 供应 | 表2 | 供应.表2 |
销售者 | 销售 | 表3 | 销售.表3 |
用户 | 架构 | 表 | 表全称 |
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 数据库设计与角色