數據庫中Schema和Database有什麼區別

　　在MySQL中建立一個Schema好像就跟建立一個Database是同樣的效果，

　　在SQL Server和Orcal數據庫中好像又不同。

　　目前我只能理解，在mysql中 schema<==>database。

 

　　數據庫中User和Schema的關係

　　假如咱們想了解數據庫中的User和Schema到底是什麼關係，首先必須瞭解一下數據庫中User和Schema究竟是什麼概念。

 

　　在SQL Server 2000中，因爲架構的緣由，User和Schema總有一層隱含的關係，讓咱們不多意識到其實User和Schema是兩種徹底不一樣的概念，不過在SQL Server 2005中這種架構被打破了，User和Schema也被分開了。

 

　　首先我來作一個比喻，什麼是Database，什麼是Schema，什麼是Table，什麼是列，什麼是行，什麼是User？

　　咱們能夠能夠把Database看做是一個大倉庫，倉庫分了不少不少的房間，Schema就是其中的房間，一個Schema表明一個房間，Table能夠看做是每一個Schema中的牀，Table（牀）就被放入每一個房間中，不能放置在房間以外，那豈不是晚上睡覺無家可歸了。而後牀上能夠放置不少物品，就比如Table上能夠放置不少列和行同樣，數據庫中存儲數據的基本單元是Table，現實中每一個倉庫放置物品的基本單位就是牀， User就是每一個Schema的主人，（因此Schema包含的是Object，而不是User），其實User是對應與數據庫的（即User是每一個對應數據庫的主人），既然有操做數據庫（倉庫）的權利，就確定有操做數據庫中每一個Schema（房間）的權利，就是說每一個數據庫映射的User有每一個Schema（房間）的鑰匙，換句話說，若是他是某個倉庫的主人，那麼這個倉庫的使用權和倉庫中的全部東西都是他的（包括房間），他有徹底的操做權，能夠扔掉不用的東西從每一個房間，也能夠放置一些有用的東西到某一個房間，呵呵，和現實也太類似了吧。我還能夠給User分配具體的權限，也就是他到某一個房間能作些什麼，是隻能看（Read-Only），仍是能夠像主人同樣有全部的控制權（R/W），這個就要看這個User所對應的角色Role了，至於分配權限的問題，我留在之後單獨的blog中詳述。比喻到這裏，相信你們都清楚了吧。

 

　　在SQL Server2000中，假如咱們在某一個數據庫中建立了用戶Bosco，按麼此時後臺也爲咱們默認地建立了默認Schema 【Bosco】。Schema的名字和User的名字相同，這也是咱們分不清楚用戶和Schema的緣由。

 

　　在SQL Server2005中，爲了向後兼容，當你用sp_adduser 存儲過程建立一個用戶的時候，SQL Server2005同時也建立了一個和用戶名相同的Schema，然而這個存儲過程是爲了向後兼容才保留的，咱們應該逐漸熟悉用新的DDL語言Create User和Create Schema來操做數據庫。在SQL Server2005中，當咱們用Create User建立數據庫用戶時，咱們能夠爲該用戶指定一個已經存在的Schema做爲默認Schema，若是咱們不指定，則該用戶所默認的Schema即爲dbo Schema，dbo 房間（Schema）比如一個大的公共房間，在當前登陸用戶沒有默認Schema的前提下，若是你在大倉庫中進行一些操做，好比Create Tabe，若是沒有指定特定的房間（Schema），那麼你的物品就只好放進公共的dbo房間（Schema）了。可是若是當前登陸用戶有默認的Schema，那麼所作的一切操做都是在默認Schema上進行（好比當前登陸用戶爲login1，該用戶的默認Schema爲login1，那麼所作的全部操做都是在這個login1默認Schema上進行的。實驗已經證實的確如此）。估計此時你會有一點暈，爲何呢？我剛纔說dbo是一個Schema，可是你能夠在數據庫中查看到，dbo同時也是一個user，暈了吧，呵呵。

 

　　在SQL Server2005中建立一個數據庫的時候，會有一些Schema包括進去，被包括進去的Schema有：dbo，INFORMATION_SCHEMA, guest，sys等等（還有一些角色Schema，不提了，有暈了）。

 

　　我在上文中已經提到了，在SQL Server2005中當用存儲過程sp_adduser建立一個user時，同時SQL Server2005也爲咱們建立了一個默認的和用戶名相同的Schema，這個時候問題出來了，當咱們create table A時，若是沒有特定的Schema作前綴，這個A表建立在了哪一個Schema上，即進入了哪一個房間？答案是：

 

　　1.若是當前操做數據庫的用戶（能夠用Select current_user查出來）有默認的Schema（在建立用戶的時候指定了），那麼表A被建立在了默認的Schema上。

 

　　2.若是當前操做數據庫的用戶沒有默認的Schema（即在建立User的時候默認爲空），可是有一個和用戶名同名的Schema，那麼表A照樣被建立在了dbo Schema上，即便有一個和用戶名同名的Schema存在，因爲它不是該用戶默認的Schema，因此建立表的時候是不會考慮的，看成通常的Schema來處理，別看名字相同，但是沒有任何關係哦。

 

　　3.若是在建立表A的時候指定了特定的Schema作前綴，則表A被建立在了指定的 Schema上（有權限嗎？）

 

　　如今問題又出來了，在當前操做數據庫的用戶（用select current_user能夠查看到，再次強調）沒有默認Schema的前提下，當咱們用Create table A語句時，A表會去尋找dbo Schema，並試圖建立在dbo Schema上，可是若是建立A表的用戶只有對dbo Schema的只讀權限，而沒有寫的權限呢？這個時候A表既不是創建不成功，這個就是我之後會說起到的Login,User, Role和Schema四者之間的關係。在這裏，爲了不混淆和提升操做數據庫的速度（在少許數據範圍內，對咱們肉眼來講幾乎看不到差別），咱們最好每次在操做數據庫對象的時候都顯式地指定特定的Schema最爲前綴。

 

　　如今若是登陸的用戶爲Sue，該用戶有一個默認Schema也爲Sue，那麼若是如今有一條查詢語句爲Select * from mytable, 那麼搜尋每一個房間（Schema）的順序是怎樣的呢？順序以下： 

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

　　2. 而後搜尋Sue.mytable (Default Schema) 

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

　　執行的順序你們既然清楚了，那麼之後在查詢數據庫表中的數據時，最好指定特定的Schema前綴，這樣子，數據庫就不用去掃描Sys Schema了，固然能夠提升查詢的速度了。

 　　另外須要提示一下的是，每一個數據庫在建立後，有4個Schema是必須的（刪都刪不掉），這4個Schema爲：dbo，guest，sys和INFORMATION_SCHEMA，其他的Schema均可以刪除。