SQL SERVER 中的Schema详解

以往 SQL Server 内的对象命名是“服务器.数据库.用户名.对象”，但新版的对象命名改成“服务器.数据库.Schema.对象”。这让你规划数据库对象命名时更有弹性。

   架构是造成单个命名空间的数据库实体的集合。命名空间是一个集合，其中每一个元素的名称都是惟一的。

   虽然 SQL Server 2000 包含 CREATE SCHEMA 语句，但实际上并不会像上面所定义的那样建立架构。在 SQL Server 2000 中，数据库用户和架构是隐式链接在一块儿的。每一个数据库用户都是与该用户同名的架构的全部者。对象的全部者在功能上与包含它的架构全部者相同。于是，SQL Server 2000 中的彻底限定名称的“架构”也是数据库中的用户。所以，从 SQL Server 2000 数据库中删除用户以前，管理员须要删除该用户所拥有的全部对象或更改这些对象的全部者。以包含此对象的 SQL Server 2000 数据库为例：

   accounting.ap.george.reconciliation

   此对象的全部者为用户“george”。若是管理员须要删除用户“george”，则必须先删除此对象或更改此对象的全部者。在后一种状况下，能够按以下方式将其重命名：

   accounting.ap.sandra.reconciliation

   转让对象的全部权也会更改其彻底限定名称。引用 accounting.ap.george.reconciliation 的任何代码必须通过更新以反映对名称所作的更改。

   在 SQL Server 2005 中，架构独立于建立它们的数据库用户而存在。能够在不更改架构名称的状况下转让架构的全部权。而且能够在架构中建立具备用户友好名称的对象，明确指示对象的功能。例如，除了 accounting.ap.sandra.reconciliation 外，您还能够建立名为 accounting.ap.invoice.reconciliation 的架构。由于“invoice”不是用户，因此从数据库中删除用户后，无需更改此名称。这就简化了数据库管理员和开发人员的工做。

   用户架构分离的好处

   将架构与数据库用户分离对管理员和开发人员而言有下列好处：

   多个用户能够经过角色成员身份或 Windows 组成员身份拥有一个架构。这扩展了容许角色和组拥有对象的用户熟悉的功能。 

   极大地简化了删除数据库用户的操做。 

   删除数据库用户不须要重命名该用户架构所包含的对象。于是，在删除建立架构所含对象的用户后，再也不须要修改和测试显式引用这些对象的应用程序。 

   多个用户能够共享一个默认架构以进行统一名称解析。 

   开发人员经过共享默认架构能够将共享对象存储在为特定应用程序专门建立的架构中，而不是 DBO 架构中。 

   能够用比早期版本中的粒度更大的粒度管理架构和架构包含的对象的权限。

   彻底限定的对象名称如今包含四部分：server.database.schema.object。 

   用户与架构（schema）分开，让数据库内各对象?再绑在某个用户帐号上，能够解决以前版本“用户离开公司＂问题，也就是在拥有该对象的用户离开公司，或离开该职务时，?必要大费周章地?改该用户全部的对象属于新的用户全部。另外，也可以让 DBA 在安装某个套装软件时，设置该套装软件所用的数据库对象都属于某个特定的架构，容?区别。也就是说，在单一数据库内，?同部门或目的的对象，能够经过架构区分?同的对象命名原则与权限。

   默认架构

   SQL Server 2005 还引入了“默认架构”的概念，用于解析未使用其彻底限定名称引用的对象的名称。在 SQL Server 2000 中，首先检查的是调用数据库用户所拥有的架构，而后是 DBO 拥有的架构。在 SQL Server 2005 中，每一个用户都有一个默认架构，用于指定服务器在解析对象的名称时将要搜索的第一个架构。可使用 CREATE USER 和 ALTER USER 的 DEFAULT_SCHEMA 选项设置和更改默认架构。若是未定义 DEFAULT_SCHEMA，则数据库用户将把 DBO 做为其默认架构。

   SQL Server 2005 Database Engine 管理着能够经过权限进行保护的实体的分层集合。这些实体称为“安全对象”。在安全对象中，最突出的是服务器和数据库，但能够在更细的级别上设置离散权限。SQL Server 经过验证主体是否已得到适当的权限来控制主体对安全对象执行的操做。

我相信不少人接触这些概念的时候一头雾水。要把这些概念理清楚真不是件容易的事，哪像原始社会，只要能分清楚什么能吃什么不能吃就好了。

可是我始终坚信，每个概念的产生必然是由于碰到了没法解决的问题。换句话说，若是没有它，必然会致使某些问题难以解决。因此我想从这个角度切入，但愿能把这几个复杂而暧昧的多角关系从最实用的角度来阐述清楚。

在问题的最初，咱们假定的数据库什么都没有。

数据库对象。首先,数据库对象是比较容易懂的。全部的表,视图，存储过程，触发器都称为数据库对象。

咱们能够拿一个网站来作类比。一个网站包含不少的网页，图片，脚本文件，咱们姑且称它为网站对象。

显然，咱们不可能把全部的网站对象都放到一个文件夹下面，一样道理，数据库对象也不可能象煮饺子同样就在数据库里这么一锅出。对于网站，咱们一般会把不一样模块的文件放在不一样的子文件夹下，那么谁是存放数据库对象的文件夹呢？答案就是：架构（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块一个月雇个仓库管理员，每一个进仓库拿东西的人都要登记。李老板还给给仓库管理员一个清单，谁能够拿什么东西，清单以下：

 

 

这时的管理上了一个新台阶，称为用户-权限管理阶段。公司再也没发生丢东西的现象。老板很是得意本身英明的决定。这就很是相似windows如今的用户权限管理了。

 

也许有人细心的发现，你说的不对，windows权限管理中有角色呀！没错，为何要有角色呢？没有角色不是照样不丢东西吗？这个问题稍后再谈。

话说过了一年，李老板的生意越作越大，仓库里的东西也愈来愈多，最近张三反应，去仓库取货总是要排队，并且常常要等好久才能取到货，李老板心想，取货的人一共就这几我的，还要排队，岂有此理！把仓库保管员叫过来！保管员早有准备，递给李老板一份最新的清单：

 

 

每次来一我的取货，保管员都要根据这张清单对一千个货物，幸好取货的人少，若是再多几我的的话，估计就要在仓库门口打架了。李老板又开始琢磨了。如今东西是不会丢了，可是每次取货慢成这样，等我货再多到一万种，我这生意还能作吗？该怎么才能提升仓库管理员的效率呢？这时仓库管理员早看出李老板的心思，色咪咪看着李老板着说:“老板，再招一个管理员吧，我老婆恰好生完孩子在家里待业。。。”。李老板一听就火了：你当招人不用花钱啊！有了！我买5个货架就搞定了！过两天我告诉你新的管理办法，你老婆仍是在家多休息几天吧。

过了几天，老板把5个货架采购回来，放进仓库，而后给管理员一份管理手册。新的管理手册以下：

 

 

第四页，第五页省略

每次货物入库的时候，根据货架货物清单放到相应的货架上，而后贴上标签。出库的时候哦只要看货架号码就能够啦。

看到这里，也许有人恍然大悟，这不就是第一节讲的“架构Schema”吗？没错，如今咱们终于知道，架构概念的引入就是为了解决数据库对象太多很差管理的缺点。到如今为止，咱们的数据库管理就变成了用户-架构-数据库对象的模式了。

在sql server2000中，用户和架构是不分离的，到了2005才分离。其实2000中的用户和架构概念就是给张3、李四分配固定的货架。这是一种更简单的管理方法