SQL Server Schema

SQL查询是引用表时，需要为其制定模式名。 在数据库的术语中，模式就是名称空间。这种方式可以把相同特性的对象组合到一个共同的名称空间中。模式也可以保护对象，所以DBA可以给模式授予显示权限。 例如,DBA可以给用户授予模式的SELECT权限，这样，用户就可以从该模式的任意表或视图中选择行了。

SQL Server数据库中的每个对象都用由4部分组成的名字来标识。该名字的形式是 Server.DataBase.Schema.Object。表中的列并不是真正的对象，而是对象的属性。SELECT子句不指定服务器，只制定数据库、模式、对象和属性，而FROM子句要求制定服务器。四部分名字中的一些部分是可选的，如果省略了服务器名，SQL Server就假定查询运行在当前的服务器连接上。数据库也是如此, SQL Server假定当前设置的服务器环境就是对象所在的数据库。

在SQL Server中，每个用户都被赋予一个默认模式或名称空间。模式是构成名称空间的数据库对象的一个指定集合。名称空间由单个用户拥有。在名称空间中，对象不能重名。但不同名称空间或不同模式中的对象可以重名。

---

http://blog.sina.com.cn/s/blog_7952e89001010jlj.html :

数据库的初学者往往会对关系型数据库模式（schema）、数据库（database）、表（table）、用户（user）之间感到迷惘，总感觉他们的关系千丝万缕，但又不知道他们的联系和区别在哪里，对一些问题往往说不出个所以然来。下面，我们就以SQL Server为核心，对其模式（schema）、数据库（database）、表（table）、用户（user）之间的关系展开讨论。

首先，我们先弄清楚什么是模式。

先明确一点，SQL Server中模式（schema）这个概念是在2005的版本里才提出来的，因此SQL Server2000不支持模式这个概念（本人曾在此处吃过亏）。

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

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

那么，现在我们来看看用户和模式（schema，即架构）有什么关系。

通过上面的分析，我们知道，一个架构可以容纳多个数据库对象，但并不是所有的用户都能访问某一个架构里的内容的，这就是所谓的权限。看下面一张表：

	User1	User2	User3	User4
Schema1	Y	Y	N	N
Schema2	N	Y	N	Y
Schema3	Y	N	Y	N

通过这张表，我们可以看出，用户1可以访问架构1和架构3，用户2可以访问架构1和架构2，以此类推。

在sql server2000中，用户和架构是不分离的，到了2005才分离。其实2000中的用户和架构概念就是为用户分配固定的模式，即如下表：

	User1	User3	User3
Schema1	Y	—	—
Schema2		Y	—
Schema3	—	—	Y

综合上面所述，用户和构架的关系是多对多的——一个架构可以对应多个用户，一个用户也可以对应多个架构。

现在，我们来讨论一下，数据库（database）和模式（schema）有什么关系。

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

因此，我们可以看到，数据库与模式时一对多的关系。

总结一下，其实我们的数据库就是一个数据的大仓库，而里面创建了很多很多模式，分别放着不同的数据库对象（包括表），而不同的模式有不同的权限，于是，不同的用户就有不同的访问权限来访问某个模式里的数据库对象。

参考资料：

http://tech.ddvip.com/2009-01/1231832216105719.html

http://tech.ddvip.com/2009-01/1231832308105720.html

---

用户架构分离的好处:

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

1. 多个用户可以通过角色成员身份或 Windows 组成员身份拥有一个架构。这扩展了允许角色和组拥有对象的用户熟悉的功能。
2. 极大地简化了删除数据库用户的操作。
3. 删除数据库用户不需要重命名该用户架构所包含的对象。因而，在删除创建架构所含对象的用户后，不再需要修改和测试显式引用这些对象的应用程序。
4. 多个用户可以共享一个默认架构以进行统一名称解析。
5. 开发人员通过共享默认架构可以将共享对象存储在为特定应用程序专门创建的架构中，而不是 DBO 架构中。
6. 可以用比早期版本中的粒度更大的粒度管理架构和架构包含的对象的权限。