在SQL Server2000中，由于架構(gòu)的原因，User和Schema總有一層隱含的關(guān)系，讓我們很少意識到其實User和Schema是兩種完全不同的概念，不過在SQL Server2005中這種架構(gòu)被打破了，User和Schema也被分開了。

首先我來做一個比喻，什么是Database，什么是Schema，什么是Table，什么是列，什么是行，什么是User？我們可以可以把Database看作是一個大倉庫，倉庫分了很多很多的房間，Schema就是其中的房間，一個Schema代表一個房間，Table可以看作是每個Schema中的床，Table（床）就被放入每個房間中，不能放置在房間之外，那豈不是晚上睡覺無家可歸了J。，然后床上可以放置很多物品，就好比Table上可以放置很多列和行一樣，數(shù)據(jù)庫中存儲數(shù)據(jù)的基本單元是Table，現(xiàn)實中每個倉庫放置物品的基本單位就是床， User就是每個Schema的主人，（所以Schema包含的是Object，而不是User），其實User是對應(yīng)與數(shù)據(jù)庫的（即User是每個對應(yīng)數(shù)據(jù)庫的主人），既然有操作數(shù)據(jù)庫（倉庫）的權(quán)利，就肯定有操作數(shù)據(jù)庫中每個Schema（房間）的權(quán)利，就是說每個數(shù)據(jù)庫映射的User有每個Schema（房間）的鑰匙，換句話說，如果他是某個倉庫的主人，那么這個倉庫的使用權(quán)和倉庫中的所有東西都是他的（包括房間），他有完全的操作權(quán)，可以扔掉不用的東西從每個房間，也可以放置一些有用的東西到某一個房間，呵呵，和現(xiàn)實也太相似了吧。我還可以給User分配具體的權(quán)限，也就是他到某一個房間能做些什么，是只能看（Read-Only），還是可以像主人一樣有所有的控制權(quán)（R/W），這個就要看這個User所對應(yīng)的角色Role了，至于分配權(quán)限的問題，我留在以后單獨的blog中詳述。比喻到這里，相信大家都清楚了吧。

在SQL Server2000中，假如我們在某一個數(shù)據(jù)庫中創(chuàng)建了用戶Bosco，按么此時后臺也為我們默認(rèn)地創(chuàng)建了默認(rèn)Schema 【Bosco】。Schema的名字和User的名字相同，這也是我們分不清楚用戶和Schema的原因。

在SQL Server2005中，為了向后兼容，當(dāng)你用sp_adduser 存儲過程創(chuàng)建一個用戶的時候，SQL Server2005同時也創(chuàng)建了一個和用戶名相同的Schema，然而這個存儲過程是為了向后兼容才保留的，我們應(yīng)該逐漸熟悉用新的DDL語言Create User和Create Schema來操作數(shù)據(jù)庫。在SQL Server2005中，當(dāng)我們用Create User創(chuàng)建數(shù)據(jù)庫用戶時，我們可以為該用戶指定一個已經(jīng)存在的Schema作為默認(rèn)Schema，如果我們不指定，則該用戶所默認(rèn)的Schema即為dbo Schema，dbo 房間（Schema）好比一個大的公共房間，在當(dāng)前登錄用戶沒有默認(rèn)Schema的前提下，如果你在大倉庫中進(jìn)行一些操作，比如Create Tabe，如果沒有指定特定的房間（Schema），那么你的物品就只好放進(jìn)公共的dbo房間（Schema）了。但是如果當(dāng)前登錄用戶有默認(rèn)的Schema，那么所做的一切操作都是在默認(rèn)Schema上進(jìn)行（比如當(dāng)前登錄用戶為login1，該用戶的默認(rèn)Schema為login1，那么所做的所有操作都是在這個login1默認(rèn)Schema上進(jìn)行的。實驗已經(jīng)證明的確如此）。估計此時你會有一點暈，為什么呢？我剛才說dbo是一個Schema，但是你可以在數(shù)據(jù)庫中查看到，dbo同時也是一個user，暈了吧，呵呵。

在SQL Server2005中創(chuàng)建一個數(shù)據(jù)庫的時候，會有一些Schema包括進(jìn)去，被包括進(jìn)去的Schema有：dbo，INFORMATION_SCHEMA, guest，sys等等（還有一些角色Schema，不提了，有暈了）。

我在上文中已經(jīng)提到了，在SQL Server2005中當(dāng)用存儲過程sp_adduser創(chuàng)建一個user時，同時SQL Server2005也為我們創(chuàng)建了一個默認(rèn)的和用戶名相同的Schema，這個時候問題出來了，當(dāng)我們create table A時，如果沒有特定的Schema做前綴，這個A表創(chuàng)建在了哪個Schema上，即進(jìn)入了哪個房間？答案是：

1.如果當(dāng)前操作數(shù)據(jù)庫的用戶（可以用Select current_user查出來）有默認(rèn)的Schema（在創(chuàng)建用戶的時候指定了），那么表A被創(chuàng)建在了默認(rèn)的Schema上。

2.如果當(dāng)前操作數(shù)據(jù)庫的用戶沒有默認(rèn)的Schema（即在創(chuàng)建User的時候默認(rèn)為空），但是有一個和用戶名同名的Schema，那么表A照樣被創(chuàng)建在了dbo Schema上，即使有一個和用戶名同名的Schema存在，由于它不是該用戶默認(rèn)的Schema，所以創(chuàng)建表的時候是不會考慮的，當(dāng)作一般的Schema來處理，別看名字相同，可是沒有任何關(guān)系哦。

3.如果在創(chuàng)建表A的時候指定了特定的Schema做前綴，則表A被創(chuàng)建在了指定的 Schema上（有權(quán)限嗎？）

現(xiàn)在問題又出來了，在當(dāng)前操作數(shù)據(jù)庫的用戶（用select current_user可以查看到，再次強調(diào)）沒有默認(rèn)Schema的前提下，當(dāng)我們用Create table A語句時，A表會去尋找dbo Schema，并試圖創(chuàng)建在dbo Schema上，但是如果創(chuàng)建A表的用戶只有對dbo Schema的只讀權(quán)限，而沒有寫的權(quán)限呢？這個時候A表既不是建立不成功，這個就是我以后會提及到的Login,User, Role和Schema四者之間的關(guān)系。在這里，為了避免混淆和提高操作數(shù)據(jù)庫的速度（在少量數(shù)據(jù)范圍內(nèi)，對我們?nèi)庋蹃碚f幾乎看不到差異），我們最好每次在操作數(shù)據(jù)庫對象的時候都顯式地指定特定的Schema最為前綴。

現(xiàn)在如果登錄的用戶為Sue，該用戶有一個默認(rèn)Schema也為Sue，那么如果現(xiàn)在有一條查詢語句為Select * from mytable, 那么搜尋每個房間（Schema）的順序是怎樣的呢？順序如下：

1. 首先搜尋sys.mytable （Sys Schema）

2. 然后搜尋Sue.mytable (Default Schema)

3. 最后搜尋 dbo.mytable (Dbo Schema)

執(zhí)行的順序大家既然清楚了，那么以后在查詢數(shù)據(jù)庫表中的數(shù)據(jù)時，最好指定特定的Schema前綴，這樣子，數(shù)據(jù)庫就不用去掃描Sys Schema了，當(dāng)然可以提高查詢的速度了。

另外需要提示一下的是，每個數(shù)據(jù)庫在創(chuàng)建后，有4個Schema是必須的（刪都刪不掉），這4個Schema為：dbo，guest，sys和INFORMATION_SCHEMA，其余的Schema都可以刪除。