但是我始终坚信,每一个概念的产生必然是因为碰到了无法解决的问题。换句话说,如果没有它,必然会导致某些问题难以解决。所以我想从这个角度切入,希望能把这几个复杂而暧昧的多角关系从最实用的角度来阐述清楚。
在问题的最初,我们假定的数据库什么都没有。
数据库对象。首先,数据库对象是比较容易懂的。所有的表,视图,存储过程,触发器都称为数据库对象。
我们可以拿一个网站来做类比。一个网站包含很多的网页,图片,脚本文件,我们姑且称它为网站对象。
显然,我们不可能把所有的网站对象都放到一个文件夹下面,同样道理,数据库对象也不可能象煮饺子一样就在数据库里这么一锅出。对于网站,我们通常会把不同模块的文件放在不同的子文件夹下,那么谁是存放数据库对象的文件夹呢?答案就是:架构(Schema).
架构(Schema)。微软的官方说明(MSDN): "数据库架构是一个独立于数据库用户的非重复命名空间,您可以将架构视为对象的容器",详细参考http://technet.microsoft.com/zh-cn/library/ms190387.aspx.我们知道,在JAVA中,命名空间名其实就是文件夹名。因此我们非常明确一点:一个对象只能属于一个架构,就像一个文件只能存放于一个文件夹中一样。与文件夹不同的是,架构是不能嵌套的,如此而已。因此,我们要访问一个数据库对象的时候,通常应该是引用它的全名"架构名. 对象名",这点非常类似C#。
问:为什么有的时候写select * from tablename也可以执行呢?
答:这是因为default schema.当只写tablename时,Sql Server会自动加上当前登录用户的default schema。
如果此表不属于当前登录用户的default schema,将会提示无效的对象名。
加上shcema以后成功。
不过我们也可以更改当前用户的default schema,这时就可以不用加前缀了。
Code
ALTER USER dbo WITH DEFAULT_SCHEMA =emdbuser;
当然,我们也可以改变此表的schema,相当于把这个表放到另一个文件夹,从emdbuser放到dbo中。
Code
alter schema dbo TRANSFER emdbuser.Borrower
以上两种作法在真实项目中都不应该作为解决方案,因为它改变了原来的设置。我们最希望的是,即使我们以dbo登陆,我们也可以伪装成emdbuser来操作数据库对象,伪装完了还能切换回来。在Sql Server中,刚好有这样的语句实现这个功能。
Code
EXECUTE AS USER = 'emdbuser';
这种机制被称为“上下文切换”,操作完以后,可以实用REVERT命令切换回来。(.NET中也有类似的机制,它们有共同的一个名称叫做Impersonate,角色扮演。)
详细解释参照MSDNhttp://msdn.microsoft.com/zh-cn/library/bb153640(SQL.90).aspx
问:如何根据表名获取一个表的Schema呢?
答:可以参照以下SQL语句从sys.objects视图和sys.schemas视图中获取。
Code
select sys.objects.name,
sys.schemas.name
from sys.objects,
sys.schemas
where sys.objects.type='U'
and sys.objects.schema_id=sys.schemas.schema_id
结论:架构就是数据库对象的容器。数据库对象是饮料,架构就是杯子,谁拿杯子喝水呢?当然是用户,那么是不是一个用户只能用一个杯子,一个杯子是不是从一而终,只能给一个人用呢?。请看第二节。
在第一节中,我们了解了架构的意义。在第二节的开始,我们暂时忘记架构这个东西。我们假设我们的数据库只有数据库对象。
李老板开了一个小公司,公司有个仓库,堆放了一些货物,由于仓库小,为了节约成本,这个仓库根本没有锁。只要知道仓库在哪里,就可以去取货。这种情况对应数据库来说,就是只要我知道数据库名和表名,我就可以对它进行操作。这对程序员来说当然是最方便了。这就是数据库的第一阶段:无权限 管理 阶段。假如大家用过Win3.X,那它们基本就是无权限管理阶段。这下小偷就爽翻了。
最近仓库里的东西老是不翼而飞。李老板才明白,就算是员工都是自觉的,但是别的人也可以拿走里面的货物,怎么办呢?老板一咬牙,花一百块钱买了一把锁!并且只给少数几个人配钥匙。这下东西被别的公司的人拿走的情况基本杜绝了。对于数据库来说,相当于把人分成了两种,一种授权用户,一种未授权用户。这时,数据库就有了用户的概念,但是它只有一个用户,就是有钥匙的人,它只对有钥匙的人开放。这就是数据库权限管理的第二阶段:上锁阶段或者单用户管理阶段。
好景不长,老板发现仓库的东西还是经常少。明明都是有钥匙的人才能进去呀。但是,谁拿了多少,根本没办法查出来。老板猜测原因有二:一,有些人拿了不该拿的东西。二,有些人偷偷的去配了钥匙。老板一咬牙,没收所有的钥匙。花800块一个月雇个仓库管理员,每个进仓库拿东西的人都要登记。李老板还给给仓库管理员一个清单,谁可以拿什么东西,清单如下:
姓名 | 货物1 | 货物2 | 货物3 | 货物4 | 货物5 |
张三 | Y | Y | N | N | N |
李四 | Y | Y | Y | N | N |
王五 | Y | Y | Y | Y | Y |
赵六 | N | Y | Y | Y | Y |
这时的管理上了一个新台阶,称为用户-权限管理阶段-角色。公司再也没发生丢东西的现象。老板非常得意自己英明的决定。这就非常类似windows现在的用户权限管理了。
也许有人细心的发现,你说的不对,windows权限管理中有角色呀!没错,为什么要有角色呢?没有角色不是照样不丢东西吗?这个问题稍后再谈。
话说过了一年,李老板的生意越做越大,仓库里的东西也越来越多,最近张三反应,去仓库取货老是要排队,而且经常要等很久才能取到货,李老板心想,取货的人一共就这几个人,还要排队,岂有此理!把仓库保管员叫过来!保管员早有准备,递给李老板一份最新的清单:
姓名 | 货物1 | 货物2 | 货物3 | 货物...... | 货物1000 |
张三 | Y | Y | N | N | N |
李四 | Y | Y | Y | N | N |
王五 | Y | Y | Y | Y | Y |
赵六 | N | Y | Y | Y | Y |
每次来一个人取货,保管员都要根据这张清单对一千个货物,幸亏取货的人少,如果再多几个人的话,估计就要在仓库门口打架了。李老板又开始琢磨了。现在东西是不会丢了,但是每次取货慢成这样,等我货再多到一万种,我这生意还能做吗?该怎么才能提高仓库管理员的效率呢?这时仓库管理员早看出李老板的心思,色咪咪看着李老板着说:“老板,再招一个管理员吧,我老婆刚好生完孩子在家里待业。。。”。李老板一听就火了:你当招人不用花钱啊!有了!我买5个货架就搞定了!过两天我告诉你新的管理办法,你老婆还是在家多休息几天吧。
过了几天,老板把5个货架采购回来,放进仓库,然后给管理员一份管理手册。新的管理手册如下:
手册第一页:货架权限清单
姓名 | 货架1 | 货架2 | 货架3 | 货架4 | 货架5 |
张三 | Y | Y | N | N | N |
李四 | Y | Y | Y | N | N |
王五 | Y | Y | Y | Y | Y |
赵六 | N | Y | Y | Y | Y |
手册第二页:1号货架货物清单
货物1 | 货物2 | 货物3 | 货物4 | 货物....... | 货架190 |
手册第三页:2号货架货物清单
货物191 | 货物192 | 货物193 | 货物194 | 货物....... | 货架390 |
第四页,第五页省略
每次货物入库的时候,根据货架货物清单放到相应的货架上,然后贴上标签。出库的时候哦只要看货架号码就可以啦。
看到这里,也许有人恍然大悟,这不就是第一节讲的“架构Schema”吗?没错,现在我们终于知道,架构概念的引入就是为了解决数据库对象太多不好管理的缺点。到现在为止,我们的数据库管理就变成了用户-架构-数据库对象的模式了。
在sql server2000中,用户和架构是不分离的,到了2005才分离。其实2000中的用户和架构概念就是给张三、李四分配固定的货架。这是一种更简单的管理方法。
姓名 | 张三的货架 | 李四的货架 | 王五的货架 | 赵六的货架 | ...的货架 |
张三 | Y | - | - | - | - |
李四 | - | Y | - | - | - |
王五 | - | - | Y | - | - |
赵六 | - | - | - | Y | - |
MS SQL2005对2000进行了很大的改进,而用户关系这部分也变得相当复杂了,很多朋友都对此一知半解!下面,我将把我应用中总结的和大家分享下,先从概念入手,希望对不理解的朋友有点提示。
今天我们要说的包括服务器登录名Server Login,服务器角色Server Role,数据库用户DB User,数据库架构DB Schema,数据库角色DB Role 。以上几个名词应该从服务器与数据库来区分,服务器包含一到多个数据库,其中:
服务器登录名,指有权限登录到某服务器的用户;
服务器角色,指一组固定的服务器用户,默认有9组;
登录名一定属于某些角色,默认为public
服务器角色不容许更改
登录后也不一定有权限操作数据库
数据库用户,指有权限能操作数据库的用户;
数据库角色,指一组固定的有某些权限的数据库角色;
数据库架构,指数据库对象的容器;
数据库用户对应于服务器登录名以便登录者可以操作数据库
数据库角色可以添加,可以定制不同权限
数据库架构,类似于数据库对象的命名空间,用户通过架构访问数据库对象
而通过下图可以让这些概念清晰一些:
即:
服务器登录名属于某组服务器角色;
服务器登录名需要于数据库的用户映射后才拥有操作数据库的权限
数据库用户属于某组数据库角色以获取操作数据库的权限
数据库角色拥有对应的数据库架构,数据库用户可以通过角色直接拥有架构
数据库用户有默认架构,写SQL语句可以直接以“对象名”访问
非默认架构则要以“架构名.对象名”访问
因此,新建一个非SA账户并建立数据库的过程可以如下:
1、新建登录名Login1
图片看不清楚?请点击这里查看原图(大图)。
2、新建数据库DB1
图片看不清楚?请点击这里查看原图(大图)。
3、新建DB1的架构Schema1
图片看不清楚?请点击这里查看原图(大图)。
4、新建BD1的用户User1,登录名对应Login1,默认架构选择Schema1,角色选择db_owner
图片看不清楚?请点击这里查看原图(大图)。
5、在登录名Login1的属性窗口里选择“用户映射”,勾选DB1,在用户里填写User1,默认架构选择"Schema1"
图片看不清楚?请点击这里查看原图(大图)。
6、至此,新建表名会是Schema1.Table1,其他对象也如此
图片看不清楚?请点击这里查看原图(大图)。
7、当然还可以新建其他架构的对象Schema2,只有User1拥有该架构,一样可以访问,如Schema2.Table2
值得注意的是,当为登录映射数据库用户的时候,多个数据库可以有相同名称的用户,而单独为某个数据库新建的用户,如User1,则在其他数据库里不允许同名。
以上就是全文,希望对大家理解并创建数据库有些帮助,也请大家多多交流。