SQL server中的模式/架构（schema）

sql server 中的模式/架构（schema）

SQL Server中模式（schema）这个概念是在2005的版本里才提出来的，因此SQL Server2000不支持模式这个概念

模式又称架构，架构的定义是形成单个命名空间的数据库实体的集合。命名空间是一个集合，其中每个元素的名称都是唯一的。在这里，我们可以将架构看成一个存放数据库中对象的一个容器。

上面的文字描述过于晦涩，举个简单的例子，平时要在电脑硬盘存放东西时，我们不会把所有的东西都存在一个文件夹里，而是会把不同的文件按照某一个标准分门别类，放到不同的文件夹里。而在数据库中，起到这个作用的就是架构，数据库对象（表、视图、存储过程，触发器等）按照一定的标准，存放在不同的架构里。有过java编程经验的同学都知道，命名空间名其实就是文件夹名，因此我们非常明确一点：一个对象只能属于一个架构，就像一个文件只能存放于一个文件夹中一样。与文件夹不同的是，架构是不能嵌套的，如此而已。因此，架构的好处非常明显——便于管理。

举个例子，我们可以把数据库看作是一个大仓库，仓库分了很多很多的房间，Schema就是其中的房间，一个Schema代表一个房间，于是乎，在不同的房间里，我们可以放不同的东西——有的放食物，有的放衣物……而这些不同的东西，就对应着我们数据库里的对象。

用户架构分离的好处

1. 架构管理与用户管理分开。多个用户可以通过角色（Role）或组（Windows Groups）成员关系拥有同一个架构。在SQL SERVER 2005/2008 中，每个数据库中的固定数据库角色都有一个属于自己的架构，如果我们创建一个表，给它指定的架构名称为 db_ddladmin，那么任何一个属于db_ddladmin中的用户都是可以去查询、修改和删除属于这个架构中的表，但是不属于这个组的用户是没有对这个架构中的表进行操作的权限。
2. 在创建数据库用户时，可以指定该用户账号所属的默认架构,若不指定默认架构，则为dbo。大多数用户在创建对象的时候习惯直接输入对象名而将对象的架构名称省略，在2005/2008 中，用户如果没有设置自己的默认架构，会给这样创建的对象加上一个缺省的架构dbo，也就是说，如果一个db_ddladmin的成员在数据库中创建一个没有加上架构名称的表，这个表在数据库中的完整名称应该是dbo.表名，创建者在数据库中如果不是属于其它特殊组的成员，是不能对自己创建的表进行任何修改和查询的，那就相当于把自己赚的钱存进了别人的银行卡，自己却取不出来。
3. 删除数据库用户变得极为简单。在 SQL Server 2000 中，用户（User）和架构是隐含关联的，即每个用户拥有与其同名的架构。因此要删除一个用户，必须先删除或修改这个用户所拥有的所有数据库对象。SQL SERVER 2005/2008将架构和对象者分离后就不在存在这样的问题，删除用户的时候不需要重命名该用户架构所包含的对象，在删除创建架构所含对象的用户后，不再需要修改和测试显式引用这些对象的应用程序。
4. 区分不同业务处理需要的对象，例如，我们可以把公共的表设置成Pub的架构，把销售相关的设置为Sales，这样管理和访问起来更容易。
5. 在架构和架构所包含的对象上设置权限（Permissions）比以前的版本拥有更高的可管理性。
6. 当查找对象时，先找与用户默认架构相同的架构下的对象，找不到再找dbo的对象。

sql server 修改表的模式schema

创建schema并赋予wang这个用户这个schema的权限

create schema  myschema  authorization  wang;

修改当前表的schema

use myDB  --使用的数据库
go
 
create schema myschema  --如果没有此schema就先建立
go
 
alter schema myschema transfer dbo.myTable   --移动对象至建立的schema下
go

删除schema

drop schema wang cascade;

其中，CASCADE（级联）表示删除模式的同时把该模式中所有的数据库对象全部删除。同时也可以改为RESTRICT（限制），表示如果该模式中已经定义了下属的数据库对象（如表、视图等），则拒绝该删除语句的执行。