源自：（）

SQL Server 2005最酷的一个特性是其新的命名规则，它向对象名加入了架构（schema）的概念。现在，在SQL Server 2005里一个完整的、符合要求的对象名由用小数点隔开的四个部分构成，就像下面这样：

[[[server.] [database].] [schema].] database-object]

这个命名规则表示只有第四个元素是强制要求必须有的。要知道你可以（在某些情况下必须）指定的内容，就要从右向左读这个语句。

很显然，你必须指定最初的对象名，这要假设你已经用到了将要操作的数据库。此外，你可以通过指定它驻留的架构来认可这个对象。如果你在另外一个数据库里引用这个架构，那么数据库和架构这两个部分都是必需的。最后，你可以告诉SQL引擎在另外一个服务器上查找要使用的数据库。

架构的优势

第一个显著的优势是再次分割数据库的能力，而不像Erwin建模工具一样让你创建对象区域（subject area）。你的数据库越丰富（也就是说它含有的表格越多），那么你通过使用架构对象获得的好处就越大，因为它能够让你在应用程序的特定部分里只包含所需要的表格。

你可以在示例数据库里看到这一点。如果运行，然后通过“Databases（数据库）／AdventureWorks／Security（安全）／Schemas（架构）”菜单找到“Object Explorer（对象浏览器）”，那么你会看到标准的角色（db_accessadmin、db_backupoperator、dbo以及其他）现在都被识别为架构，并带有AdventureWorks专用的架构：HumanResources、Person、Production、Purchasing和Sales。如果你双击架构树中的任何一个架构，那么“Schema Properties（架构属性）”对话框就会出现，如所示。

如图A所示，对话框里有三个节点，每一个都会显示相关的属性。显示的是这个对话框的“Permissions（权限）”面板。通过“Add（添加）”按钮，你可以选择一个或者多个对象，并授予或者撤销它们的权限。在角色、明确的权限，以及架构权限都不存在的情况下，SQL引擎将假设每用户都能够访问对象。如果你创建了一个对象而没有指定其架构，那么SQL将（按照默认的设置）把它放到dbo架构里。

显示了架构最有价值的一面：对象通过对象区域和名字来排序。在创建新的查询时，你可以把要用到的对象拖到查询里，这样符合要求的文件名就会出现。

在你第一使用的时候，新的架构限定符可能看起来完全没有必要存在；如果发现存在这种情况，你可以像自己在SQL Server 2000里面的做法一样，引擎不会阻止你。你只用把所有的对象都拖到dbo架构里就行了。

虽然AdventureWorks示例数据库要比先前的示例数据库（Northwind和Pubs）更加丰富，但是它离真正丰富的数据库还差着远呢，我把至少含有150个表格的数据库定义为丰富的数据库。我所使用的一个SQL Server 2000数据库含有超过500个表格和2000个过程。在本文中，架构真是天赐吉祥。但是架构的价值的体现并不需要这样要求很高的数据库。只要你开始使用超过20个表格的数据库，它的优势就会体现出来。它们会帮助你每次都把注意力集中在问题的一部分上，而不需要牵涉到其他所有部分。

作为探索以架构为基础工作的一种练习，我建议在调用你已经使用过一段时间的数据库是问一下自己：“如果现在我有了架构，我能有什么样的不同？”

责任编辑：

类别：