在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都可以删除。
最新内容请见作者的GitHub页:http://qaseven.github.io/