SQL Server 2005 中的架构与用户

   从 SQL Server 2005 开始，每个对象都属于一个数据库架构。数据库架构是一个独立于数据库用户的非重复命名空间。您可以将架构视为对象的容器。可以在数据库中创建和更改架构，并且可以授予用户访问架构的权限。任何用户都可以拥有架构，并且架构所有权可以转移。

 

首先我们从安全对象来了解架构：

 

如图1：

 

 

使用图形表示，这样我们更能方便的了解架构，和她在安全对象中所处的位置及与其他安全对象的关系。

找到一张，如图，数据库引擎 权限层次结构之间的关系图：

 

 

这能帮助我们理解架构。

 

引用帮助文档对架构的定义：

　　从 SQL Server 2005 开始，每个对象都属于一个数据库架构。数据库架构是一个独立于数据库用户的非重复命名空间。您可以将架构视为对象的容器。可以在数据库中创建和更改架构，并且可以授予用户访问架构的权限。任何用户都可以拥有架构，并且架构所有权可以转移。

 

　　在SQL Server 2000中架构和用户是没有多大的区别，我们在2000中一般是指所有者。2005后，用户和架构开始明确的分开，架构可以理解为对象的容器或者命名空间。

 

对于架构特点的理解小节如下：

　　1.一个架构中不能包含相同名称的对象，相同名称的对象可以在不同的架构中存在。

　　

      2.一个架构只能有一个所有者，所有者可以是用户, 数据库角色, 应用程序角色。

　　

      3.一个用数据库角色可以可以拥有一个默认架构，和多个架构。

　　

      4.多个数据库用户可以共享单个默认架构。

　　

      5.由于架构与用户独立，删除用户不会删除架构中的对象。

　　

      6.SQL Server 2000 中对象引用是：

    

      [DatabaseServer].[DatabaseName].[ObjectOwner].[DatabaseObject]
　　SQL Server 2005 中对象引用是：
　　[DatabaseServer].[DatabaseName].[DatabaseSchema].[DatabaseObject]

 

可以归纳为3点：

1. 代替旧版本中的所有者, 旧版本中的所有者与用户绑定的, 而schema不与用户绑定, 从而可以避免因为用户职务变化或者离职带来的所有者修改

2. 方便权限控制, 用户直接绑定到架构上就可以对某类业务相关的对象进行操作.

3. 区分不同业务处理需要的对象, 例如, 我们可以把公共的表设置成pub的架构, 把销售相关的设置为sales, 这样管理起来更容易.