瞭解SQL Server2005新架構規則的優勢

SQL Server 2005最酷的一個特性是其新的命名規則，它向物件名加入了架構（schema）的概念。現在，在SQL Server 2005裡一個完整的、符合要求的物件名由用小數點隔開的四個部分構成，就像下面這樣：

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

這個命名規則表示只有第四個元素是強制要求必須有的。要知道你可以（在某些情況下必須）指定的內容，就要從右向左讀這個語句。

很顯然，你必須指定最初的物件名，這要假設你已經用到了將要操作的資料庫。此外，你可以通過指定它駐留的架構來認可這個物件。如果你在另外一個資料庫裡引用這個架構，那麼資料庫和架構這兩個部分都是必需的。最後，你可以告訴SQL引擎在另外一個伺服器上查詢要使用的資料庫。

架構的優勢

第一個顯著的優勢是再次分割資料庫的能力，而不像Erwin建模工具一樣讓你建立物件區域（subject area）。你的資料庫越豐富（也就是說它含有的表格越多），那麼你通過使用架構物件獲得的好處就越大，因為它能夠讓你在應用程式的特定部分裡只包含所需要的表格。

你可以在AdventureWorks示例資料庫裡看到這一點。如果執行Management Studio，然後通過“Databases（資料庫）／AdventureWorks／Security（安全）／Schemas（架構）”選單找到“Object Explorer（物件瀏覽器）”，那麼你會看到標準的角色（db_accessadmin、db_backupoperator、dbo以及其他）現在都被識別為架構，並帶有AdventureWorks專用的架構：HumanResources、Person、Production、Purchasing和Sales。如果你雙擊架構樹中的任何一個架構，那麼“Schema Properties（架構屬性）”對話方塊就會出現，如圖A所示。

如圖A所示，對話方塊裡有三個節點，每一個都會顯示相關的屬性。圖B顯示的是這個對話方塊的“Permissions（許可權）”皮膚。通過“Add（新增）”按鈕，你可以選擇一個或者多個物件，並授予或者撤銷它們的許可權。在角色、明確的許可權，以及架構許可權都不存在的情況下，SQL引擎將假設每使用者都能夠訪問物件。如果你建立了一個物件而沒有指定其架構，那麼SQL將（按照預設的設定）把它放到dbo架構裡。

圖C顯示了架構最有價值的一面：物件通過物件區域和名字來排序。在建立新的查詢時，你可以把要用到的物件拖到查詢裡，這樣符合要求的檔名就會出現。

在你第一使用的時候，新的架構限定符可能看起來完全沒有必要存在；如果發現存在這種情況，你可以像自己在SQL Server 2000裡面的做法一樣，引擎不會阻止你。你只用把所有的物件都拖到dbo架構裡就行了。

雖然AdventureWorks示例資料庫要比先前的示例資料庫（Northwind和Pubs）更加豐富，但是它離真正豐富的資料庫還差著遠呢，我把至少含有150個表格的資料庫定義為豐富的資料庫。我所使用的一個SQL Server 2000資料庫含有超過500個表格和2000個過程。在本文中，架構真是天賜吉祥。但是架構的價值的體現並不需要這樣要求很高的資料庫。只要你開始使用超過20個表格的資料庫，它的優勢就會體現出來。它們會幫助你每次都把注意力集中在問題的一部分上，而不需要牽涉到其他所有部分。

作為探索以架構為基礎工作的一種練習，我建議在呼叫你已經使用過一段時間的資料庫是問一下自己：“如果現在我有了架構，我能有什麼樣的不同？”

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-558070/，如需轉載，請註明出處，否則將追究法律責任。