数据库中的Schema和Database的区别
在mysql中创建一个Schema和创建一个Database的效果好像是一样的，但是在sqlserver和orcal数据库中效果又是不同的，目前我只能理解为在mysql中schema<==>database;
数据库中的user和schema的关系： 假如我们想了解数据库中的user和schema的关系，首先必须要清楚数据库中的user和schema的概念。 在sqlserver2000中，由于架构的原因，user和schema总有一层隐含的关系，让我们很少意识到其实user和schema是两种完全不同的概念，不过在sqlserver2005中这种架构被打破了，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了。 在sqlserver2000中，假如我们在某一数据库中创建了用户Bosco，那么此时后台也为我们默认的创建了schema【Bosco】，schema的名字和user的名字相同，这也是我们分不清用户和schema的原因。 在sqlserver2005中，为了向后兼容，当你用sp_adduser存储过程创建一个用户的时候，sqlserver2005同时也创建了一个和用户名相同的schema，然而这个存储过程是为了向后兼容才保留的，我们应该逐渐熟悉用新的DDL语言create user和create schema来操作数据库，在sqlserver2005中，当我们用create user创建数据库用户时，我们可以用该用户指定一个已经存在的schema作为默认的schema，如果我们不指定，则该用户所默认的schema即为dbo schema，dbo房间（schema）好比一个大的公共房间，在当前登录用户没有默认schema的前提下，如果你在大仓库中进行一些操作，比如create table，如果没有制定特定的房间（schema），那么你的物品只好放进公共的dbo房间（schema）了。但是如果当前登录用户有默认的schema，那么所做的一切操作都是在默认的schema上进行（比如当前登录用户为login1，该用户的默认schema为login1，那么所做的所以操作都是在这个login1默认schema上进行的。实验已经证明的确如此）。估计此时你会有一点晕，刚才说dbo是一个schema，但是你可以在数据库中查看到，dbo同事也是一个user，晕了吧。 在sqlserver2005中创建一个数据库的时候，会有一些schema包括进去，被包括进去的schema有：dbo，INFORMATION_SCHEMA，guest，sys等等（还有一些角色schema）。 在上文中已经提到了，在sqlserver2005中当用存储过程sp_adduser创建一个user时，同时sqlserver2005也为我们创建了一个默认的和用户名相同的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都可以删除。
