--SQL Server 2005 User and Schema（用户与架构）

架构（Schema）是一组数据库对象的集合，它被单个负责人（可以是用户或角色）所拥有并构成唯一命名空间。你可以将架构看成是对象的容器。
======================
在 SQL Server 2000 中，用户（User）和架构是隐含关联的，即每个用户拥有与其同名的架构。因此要删除一个用户，必须先删除或修改这个用户所拥有的所有数据库对象。
======================
在 SQL Server 2005 中，架构和创建它的数据库用户不再关联，完全限定名（fully-qualified name）现在包含4个部分：server.database.schema.object
======================
用户和架构分离的好处
1. 多个用户可以通过角色（role）或组（Windows groups）成员关系拥有同一个架构
2. 删除数据库用户变得极为简单。
3. 删除数据库用户不需要重命名与用户名同名的架构所包含的对象，因此也无需对显式引用数据库对象的应用程序进行修改和测试。
4. 多个用户可以共享同一个缺省架构（default schema）来统一命名。
5. 共享缺省架构使得开发人员可以为特定的应用程序创建特定的架构来存放对象，这比仅使用管理员架构（DBO schema）要好。
6. 在架构和架构所包含的对象上设置权限（permissions）比以前的版本拥有更高的可管理性。

========================
缺省架构

　　SQL Server 2005 引入了缺省架构（Default Schema）的概念，用于确定没有使用完全限定名的对象的命名。
      在 SQL Server 2005 中，缺省架构指定了服务器确定对象的名称时所查找的第一个架构。
      缺省架构可以用 CREATE USER 和 ALTER USER 中的 DEFAULT_SCHEMA 选项创建和修改。
      如果没有定义 DEFAULT_SCHEMA，则所创建的数据库用户将用 dbo 作为他的缺省架构。

 ====================================
对于网站，我们通常会把不同模块的文件放在不同的子文件夹下，那么谁是存放数据库对象的文件夹呢？
答案就是：架构（Schema）.
=====================================
架构（Schema）。微软的官方说明（MSDN）： "数据库架构是一个独立于数据库用户的非重复命名空间，您可以将架构视为对象的容器"，详细参考http://technet.microsoft.com/zh-cn/library/ms190387.aspx.
=====================================
问:为什么有的时候写select * from tablename也可以执行呢？

答:这是因为default schema.当只写tablename时，Sql Server会自动加上当前登录用户的default schema。 
=====================================
如果此表不属于当前登录用户的default schema,将会提示无效的对象名。
select * from Borrower--会报错
加上shcema以后成功。
select * from emdbuser.Borrower--运行正确
1. 不过我们也可以更改当前用户的default schema，这时就可以不用加前缀了。

ALTER USER dbo WITH DEFAULT_SCHEMA =emdbuser;

2. 当然，我们也可以改变此表的schema,相当于把这个表放到另一个文件夹,从emdbuser放到dbo中。

alter schema dbo TRANSFER emdbuser.Borrower

以上两种作法在真实项目中都不应该作为解决方案，因为它改变了原来的设置。我们最希望的是，即使我们以dbo登陆，我们也可以伪装成emdbuser来操作数据库对象，伪装完了还能切换回来。在Sql Server中,刚好有这样的语句实现这个功能。

EXECUTE AS USER = 'emdbuser';

这种机制被称为“上下文切换”，操作完以后，可以实用REVERT命令切换回来。
详细解释参照MSDNhttp://msdn.microsoft.com/zh-cn/library/bb153640(SQL.90).aspx
================================================
问:如何根据表名获取一个表的Schema呢？

答:可以参照以下SQL语句从sys.objects视图和sys.schemas视图中获取。

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

结论：架构就是数据库对象的容器。数据库对象是饮料，架构就是杯子，谁拿杯子喝水呢？当然是用户，那么是不是一个用户只能用一个杯子，一个杯子是不是从一而终，只能给一个人用呢？

from:http://www.cnblogs.com/xiaomin/archive/2009/01/12/1374186.html

**********************************************************
在第一节中，我们了解了架构的意义。在第二节的开始，我们暂时忘记架构这个东西。我们假设我们的数据库只有数据库对象。
李老板开了一个小公司，公司有个仓库，堆放了一些货物，由于仓库小，为了节约成本，这个仓库根本没有锁。只要知道仓库在哪里，就可以去取货。这种情况对应数据库来说，就是只要我知道数据库名和表名，我就可以对它进行操作。这对程序员来说当然是最方便了。这就是数据库的第一阶段：无权限管理阶段。假如大家用过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

 第四页，第五页省略

      每次货物入库的时候，根据货架货物清单放到相应的货架上，然后贴上标签，如"货架1-三星扫描仪"。出库的时候哦只要看货架号码就可以啦。
如果赵六拿着这个"货架1-三星扫描仪"就倒霉了，至少是出不了仓库的，因为赵六在货架1的权限是"N"。
====================
这就是第一节讲的“架构Schema”，架构概念的引入就是为了解决数据库对象太多不好管理的缺点。
到现在为止，我们的数据库管理就变成了用户-架构-数据库对象的模式了。
P.S.
在sql server2000中，用户和架构是不分离的，到了2005才分离。其实2000中的用户和架构概念就是给张三、李四分配固定的货架。这是一种更简单的管理方法。

姓名	张三的货架	李四的货架	王五的货架	赵六的货架	...的货架
张三	Y	-	-	-	-
李四	-	Y	-	-	-
王五	-	-	Y	-	-
赵六	-	-	-	Y	-

=================

#################
用户(User)和架构(Schema)的关系

• 一个架构(存折)有且只有一个所有者Owner(储户)。
• 一个用户(储户)可以拥有多个架构(存折)。

       这跟第二节中介绍的货架权限清单有所出入，第二节中的例子是多对多的关系，而实际Sql Server是采用一对多的关系。这反而比较像是银行账户。一个人可以有多个存折，但是一个存折只有一个用户。

• 创建一个用户，系统将自动创建一个同名的架构。
• 创建一个架构必须指定所有者，否则将默认为当前登陆用户。
• 表即使属于不同的架构也不能重名。
• 删除一个用户时，架构也会被删除？

 

架构(Schema)相关的SQL

      创建架构

 

     CREATE SCHEMA [SchemaName] AUTHORIZATION [User]

      更改架构的所有者

      删除架构

      数据库设计与架构

      架构的目的应该在于在同一数据库中提供一种隔离机制。按照这种思路，以最典型的产供销结构，我们可以这样设计一个数据库MyDatabase：

 

用户	架构	表	表全称
生产者	生产	表1	生产.表1
供应者	供应	表2	供应.表2
销售者	销售	表3	销售.表3

      这样生产者登陆以后只能操作表1，供应者登陆以后只能操作表2...隔离效果非常好。但是，如果总经理想要查看一个产供销的综合报表该如何办呢？在这样的设计下，是根本做不到的。所以我们目前看到的实际情况是，基本上一个数据库只用一个架构和一个用户登陆。

 

用户	架构	表	表全称
MyUser	MySchema	表1	MySchema.表1
		表2	MySchema.表2
		表3	MySchema.表3

 

      这下总经理要看报表是没问题了，但是这样架构就形同虚设了。这也是为什么大家搞不清楚架构和用户的关系的原因。假如一个架构可以有多个拥有者，那么就可以彻底解决这个问题。

      有人要说了，但是好像我用dbo登陆以后，是可以操作不同架构的表啊，这是为什么呢？那是因为上面的讨论是建立在没有角色的基础上的，