SQL Server 中所有者和架构之间的区别

SQL Server 2005 引入了架构的概念，而不是以前版本中的对象所有者。本文将解释两者之间的区别，并希望消除对架构仍然存在的一些困惑。

对象所有者（Object Owners）

为了理解所有者和架构之间的区别，让我们花点时间回顾一下对象所有权。在 SQL Server 2000 或更早的版本中创建对象时，该对象必须拥有所有者。大多数情况下，所有者是“dbo”，也称为数据库所有者。对象可能属于数据库中的任何用户帐户。确定所有者的方法是查看完全限定对象名称。当您查看表列表时，可以使用 SQL Server Enterprise Manager 或 Management Studio 查看完全限定对象名称。例如，dbo 拥有的名为orders 的表的名称是 dbo.orders。如果表的所有权转移到用户 abc，那么表现在将被命名为 abc.orders。

对象如何获得它的所有者?这取决于创建它的用户。db_owner 角色的人也可以创建数据库中任何用户拥有的对象。默认情况下，创建对象的用户帐户（帐户必须具有 CREATE TABLE 权限）也将拥有该对象。只有具有 db_owner 角色的用户帐户才能创建属于 dbo 的对象。即使这样，在某些情况下，所有者最终将是实际的用户帐户，而不是 dbo。

使用 dbo 作为所有数据库对象的所有者可以简化对象的管理。在数据库中始终有一个 dbo 用户。只要该用户拥有适当的权限，数据库中的用户将能够访问 dbo 拥有的任何对象，而无需指定所有者。如果对象属于 dbo 以外的帐户，则在删除原始帐户时，必须将该帐户的所有权转移给其他用户。例如，如果一个名为“ted”的非 dbo 数据库用户创建了 sales 表，那么它将被称为 ted.sales。为了让 Ted 以外的用户看到这个表，它必须由完全限定名引用。如果 Ted 离开了公司或部门，并且必须从数据库中删除他的帐户，那么必须使用 sp_changeobjectowner 存储过程将表的所有权转移到另一个用户帐户，然后才能删除 Ted 的帐户。

如果在应用程序中使用过表或在存储过程等任何定义中引用过表，那么更改所有者将破坏所有代码。如果 dbo 从一开始就拥有这个表，那么删除Ted 的帐户就没有问题。代码不需要使用完全限定名，这样做会略微提高性能，这被认为是最佳实践。

架构（Schemas）

我喜欢把架构看作是组织对象的容器。如果您看一下 AdventureWorks 示例数据库(如下图)，您将看到这些表是按部门或功能组织的，比如 “Sales” 或 “Production”。这看起来与旧的所有者概念相似，但有很多优点。首先，由于对象没有绑定到任何用户帐户，因此在删除帐户时，您不必担心更改对象的所有者。另一个优点是架构可以用于简化对表和其他对象的权限管理。架构有一个所有者，但所有者没有绑定到名称。因此，如果一个帐户拥有一个架构，并且必须从数据库中删除该帐户，则可以在不破坏任何代码的情况下更改架构的所有者。如果不希望将数据库对象组织成架构，可以使用 dbo 架构。

假设 Dev 部门中的员工是同一个网络安全组 DevEmp 的成员。每个部门的经理都是另一个组 DevManagers 的成员。我们创建了一个名为 Devs 的架构，Devs 架构中包含了许多表、视图和存储过程。为了控制对对象的访问，我们可以将 DevEmp 和 DevManagers 网络组添加到 SQL Server 和数据库中。因为我们关注的是对表的访问控制，所以 DevEmp 组被授予了 Dev 架构中所有存储过程的执行权限。DevManagers 组还被授予了对所有表和视图的选择权限。这样做的好处是，只要在 Devs 架构中创建新的存储过程、表或视图，您就不再需要记住授予权限。

要向架构中的所有存储过程授予执行权限，步骤如下：

1. 使用 SSMS 连接实例，数据库—安全性—架构；

2. 右键架构名（如Person）并选择属性；

3. 选择权限页面，单击搜索选择数据库用户或角色；

4. 一旦选择了用户或角色，底部将出现权限列表；

5. 若要向所有存储过程授予执行权限，请选中“execute”；

这样，该用户就拥有了该架构存储过程的执行权限了。该设置有类似如 db_datareader 这样的角色概念，不过除了表外没有其他相应的角色。对于给用户设置存储过程执行权限，只能像上面这样设置了。

对于架构的设置，若要变更比较麻烦。所以架构的设置一定在设计的时候考虑好，设计好了之后基本就不再更改了。通常使用最佳实践设计，默认使用架构 dbo 就好。架构的应用，在权限管理方面非常灵活，但也会增加维护复杂度，需要对架构足够了解。