理解SQL SERVER中所有者和架构的区别
SQL SERVER2005介绍了架构，架构相对于以前版本中的对象所有者。本文将解释这两者的区别，并希望能解开你至今仍对架构一点困惑。
对象所有者
要理解所有者和架构之间的区别，让我们先花点时间来复习一下对象的所有权。在SQL SERVER2000或以前版本中创建一个对象，对象必须要有一个所有者(owner)。大部分情况，所有者为“dbo（数据库所有者）”。一个对象可以被数据库中任何一个用户所拥有。判断一个对象的所有者的方法是在企业管理器或Manager Stdio中浏览表的列表时查看对象的全限定名称（full qualified）。比如，一个由dbo所拥有的表orders其全限定名为dbo.orders。如果该表的所有权转移至用户abc，那么该表现在的全限定名为abc.orders。
对象是如何属于某个所有者的呢？这依赖于创建对象时的用户。
也有可能是db_owner角色成员创建了一个由数据库中任何对象所拥有的对象。缺省情况下，创建对象的用户账号（该账户必须拥有CREATE TABLE的权限）也是对对象的所有者。只有db_owner角色成员可以创建由dbo所拥有的对象。即使那样，在某些情况下，对象的所有者还可能是实际的用户而不是dbo。
使用dbo作为数据库中所有对象的所有者可以简化对象的管理。因为数据库中永远都会有dbo用户的。数据库中的用户只要有权限可以不用指定所有者名称就可以存取由dbo拥有的对象了。如果一个对象不是被dbo所有用，那么该所有者将要被删除时，必须将对象的所有权转移给其他用户。比如有一个非dbo用户ted创建了sales表，该表名称为ted.sales。如果ted以外的用户想使用此表，那么必须使用表的全限定名来指定。如果ted离开了公司或部门，那么他的数据库用户账号必须得删除。在删除前，ted所拥有的对象必须使用存储过程sp_changeobjectowner将所有权转移至其他用户账号。
如果这个表在应用程序或者其他存储过程中使用过，改变表的所有者可能导致所有的代码出错。如果一开始该表就被dbo所拥有，那么即使删除了ted账号也没有关系。代码也不需要使用全限定名——这样可能损失点性能——来指定对象，这被认为是最实用的方法。
架构
我喜欢将架构想象成一个组织对象的容器。如果你看一下adventureworks样例数据库，你会发现表是按照部门或者功能组织起来的，比如“HumanResources”或者“Production”（图一）。这看起来有点像老的拥有者概念，但却拥有许多益处。首先，因为对象不再绑定到用户账号上，所以你根本不用担心当一个账号被删除时需要变换对象的拥有者。另一个好处是使用架构可以简化表和其他的对象的权限管理。每个架构都有其所有者，但是所有者和架构名是不绑定的。所有当一个用户拥有一个架构，并且这个用户必须从数据库中删除时，可以不用破坏任何代码而仅仅是将架构的所有者变一下。如果你不希望用架构来组织数据库中的对象，只用dbo架构就行了。
图一
我们假定widgets部门的雇员同样是网络安全组widgeemp中的成员。每个部门的经理另外还属于widgetmanagers。我们创建一个widgets架构，并在其中创建多个表、视图和存储过程。为了访问这些对象，我们可以将WidgetEmp和WidgetManagers组加入到SQL SERVER和数据库中。因为我们比较在意对表的读取，所以WidgetEmp组只被授予了widget架构中执行所有存储过程的权限；WidgetManagers组同时还被授予SELECT所有表和视图的权限。一个非常好的情况是：无论何时在widgets架构中创建一个新的存储过程、视图或表，你都不再需要记得分配权限了。
为了授予架构中所有的存储过程中的执行（EXECUTE）权限，请按如下步骤：
1.使用Management Studio，在数据库下的展开安全性，然后展开架构
2.右击架构名，选择属性。
3.选择权限页，点[添加…]加入选择的数据库用户或角色。
4.一旦用户或角色被选上，那么下面的框中将会列出其权限。
5.为了授予所有存储过程的执行权限，选择授予EXECUTE权限。
我一直想有一个可以执行所有存储过程的数据库角色，有点像db_datareader角色。现在可以通过授予架构中所有存储过程的执行权限来达到目的了（图二）。我不知道为什么没有这样的一个固定角色，不过至少现在有一个简单的解决方法了。即使你没有在数据库中利用架构，你也可以通过授予dbo架构中的所有存储过程的执行权限来达到同样的目的。
图二
有一点必须牢记
：如果你想从利用架构，你必须在数据库设计之初就考虑架构的组织。在后期改变架构的设计需要改变很多代码。
升级你的数据库
数据库如果从SQL SERVER 2000升级到2005会发生什么？当数据库从2000升级到2005，SQL SERVER为数据库中的每个用户都会创建一个架构。你可能一开始没有注意它，直到你打算删除某个数据库用户。此时你会收到报错“数据库主体拥有一个架构，不能删除”。为了解决这个问题，你可以在架构为空的时候删除架构，然后再删除用户；如果架构不空，你必须决定是删除架构中对象还是将其转移至另外的一个所有者。
总结
一开始时，架构的概念确实很让人困扰。但是如果你了解它，你将发现其很多益处。你只要将架构想象成组织对象的一个容器，可以就像早期的所有者那样简单地对其授权。最重要的是，架构组织必须在设计阶段就要早早地考虑好以避免后期的代码问题。最后，通过授予一个架构中的执行权限给一个用户或或数据库角色，我们现在可以确保用户总是可以执行新的存储过程。
原文地址：
http://www.sqlteam.com/article/understanding-the-difference-between-owners-and-schemas-in-sql-server