一、schame详解
http://www.cnblogs.com/Neo-ds/p/4790413.html
1、先明确一点，SQL Server中模式（schema）这个概念是在2005的版本里才提出来的，因此SQL Server2000不支持模式这个概念（本人曾在此处吃过亏）。
模式又称架构，架构的定义是形成单个命名空间的数据库实体的集合。命名空间是一个集合，其中每个元素的名称都是唯一的。在这里，我们可以将架构看成一个存放数据库中对象的一个容器。
上面的文字描述过于晦涩，举个简单的例子，平时要在电脑硬盘存放东西时，我们不会把所有的东西都存在一个文件夹里，而是会把不同的文件按照某一个标准分门别类，放到不同的文件夹里。而在数据库中，起到这个作用的就是架构，数据库对象（表、视图、存储过程，触发器等）按照一定的标准，存放在不同的架构里。有过java编程经验的同学都知道，命名空间名其实就是文件夹名，因此我们非常明确一点：一个对象只能属于一个架构，就像一个文件只能存放于一个文件夹中一样。与文件夹不同的是，架构是不能嵌套的，如此而已。因此，架构的好处非常明显——便于管理。
总结一下，其实我们的数据库就是一个数据的大仓库，而里面创建了很多很多模式，分别放着不同的数据库对象（包括表），而不同的模式有不同的权限，于是，不同的用户就有不同的访问权限来访问某个模式里的数据库对象。
http://blog.csdn.net/xuexiiphone/article/details/51252749
用户与架构的权限管理关系用上文中的小偷例子比较形象。
2、用户架构分离的好处:
将架构与数据库用户分离对管理员和开发人员而言有下列好处：
（1）多个用户可以通过角色成员身份或 Windows 组成员身份拥有一个架构。这扩展了允许角色和组拥有对象的用户熟悉的功能。
（2）极大地简化了删除数据库用户的操作。
（3）删除数据库用户不需要重命名该用户架构所包含的对象。因而，在删除创建架构所含对象的用户后，不再需要修改和测试显式引用这些对象的应用程序。
（4）多个用户可以共享一个默认架构以进行统一名称解析。
（5）开发人员通过共享默认架构可以将共享对象存储在为特定应用程序专门创建的架构中，而不是 DBO 架构中。
（6）可以用比早期版本中的粒度更大的粒度管理架构和架构包含的对象的权限。
二、 Sql Server需要架构(Schema)的真实原因
http://blog.csdn.net/hejisan/article/details/52292874
schema相当于一个数据库中的两个子数据库，事务回滚时能够保持数据一致性。
设想有一系统S1, 使用一数据库Db1, 另有一系统S2, 使用数据库Db1 和 Db2。S1 只操作 Db1；S2 同时操作 Db1 和Db2。系统S2知道系统S1的存在，并且需要自己的一些数据，所以创建了Db2以存放自己的数据。系统S1使用用户U1，系统S2使用用户U2，U1拥有Db1的访问权，U2拥有Db1和Db2的访问权，系统S1不知道Db2和系统S2的存在。S2 的日常操作也是在事务包装下的，并不会造成 Db1和Db2的数据不一致。S1和S2并行运行，工作良好。
直到有一天，硬件系统发生了严重故障，这时Db1 和 Db2进行日志回滚。单独检查Db1和Db2的数据，没有任何问题。
但是，Db1和Db2的数据一致性现在可能就有问题了，因为Db1 和Db2 的回滚之间没有任何同步机制。在一个涉及Db1和Db2的复杂事务中，Db1的数据可能已写入，没有被丢弃，而Db2中的数据可能在回滚时被丢弃了；反之亦然，于是产生了一致性问题。
这时，就轮到我们的主角，架构发挥用处的时候了，建立一个大的数据库Db，Db1和Db2改成为架构S1和S2，用户U1拥有架构S1的访问权，用户U2拥有架构S1和S2的访问权。你就会发现，现在任何时候都没有一致性问题了。当数据库需要回滚的时候，因为在同一数据库中，架构S1和S2之间没有任何一致性问题。
三、Sql server 2005中schema的用法总结
http://jizhonglee.blog.51cto.com/3003732/805201
用Schema 加快了查询的执行时间
在没有制定schema的情况下是按照如下的顺序执行查找的
首先搜寻sys.mytable （Sys Schema）
然后搜寻Sue.mytable (Default Schema)
最后搜寻 dbo.mytable (Dbo Schema)
如果指定schema的话就不用去扫描Sys Schema了，这样就加快了查询的时间，从而提高了执行效率。
对表的查询速度会有所提高，如果把索引跟表同在一个命名空间，那数据库表空间变小，因为索引是占空间的。这样就会影响到查询表速度。