首先我们来看一下msdn中对架构的定义:架构(Schema)是形成单个命名空间的数据库实体的集合.命名空间是一个集合,其中每个元素的名称都是唯一的.今天这一节,我们可以将架构看成一个存放数据库中对象的一个容器.
① 多个用户可以通过角色（role）或组（Windows groups）成员关系拥有同一个架构.
SQL Server 中的 架构 ( schema )
与 软件构架 与 架构师 的不是同一个概念
schema 是用于 在一个 大项目中的 各个 小项目
每个 小项目的表, 放在 各自的 schema 下面.
这样, 遇到 小项目里面. 有 相同名字的 表的话, 不会发生冲突.
例如一个 公司的 系统.
.
那么 财务系统的表, 可以放在 财务的 schema.
人力资源系统的表,放在 人力资源系统的模式里面.
但是又不因为 表重名 的问题,影响对方.
体系结构是下面这个样子的
[服务器名称].[数据库名称].[构架名称].[表名]
create database -- 创建一个数据库
create schema -- 创建一个构架
当你在 SQL Server 里面, 使用 create database 创建一个数据库以后.
你可以不必额外的去创建 schema
因为 SQL Server 会 自动的创建一个 名字叫 dbo 的 schema
架构（Schema）是一组数据库对象的集合,它被单个负责人（可以是用户或角色）所拥有并构成唯一命名空间.你可以将架构看成是对象的容器.
① 体系结构（Architecture）
体系结构亦可称为架构,所谓软件架构,根据Perry 和Wolfe之定义：Software Architecture = {Elements,Forms, Rationale / Constraint },也就是软件主架构 = {组件元素,元素互助合作之模式,基础要求与限制}.Philippe Kruchten采用上面的定义,并说明主架构之设计就是：将各组件元素以某些理想的合作模式组织起来,以达成系统的基本功能和限制.体系结构又分为多种样式,如Pipes and Filters等.
框架亦可称为应用架构,框架的一般定义就是：在特定领域基于体系结构的可重用的设计.也可以认为框架是体系结构在特定领域下的应用.框架比较出名的例子就是MVC.
库应该是可重用的、相互协作的资源的集合,供开发人员进行重复调用.它与框架的主要区别在于运行时与程序的调用关系.库是被程序调用,而框架则调用程序.比较好的库有JDK.
设计模式大家应该很熟悉,尤其四人帮所写的书更是家喻户晓."四人帮"将模式描述为"在一定的环境中解决某一问题的方案".这三个事物 — 问题、解决方案和环境 — 是模式的基本要素.给模式一个名称,考虑使用模式将产生的结果和提供一个或多个示例,对于说明模式也都是有用的.
由多种系统构成,其中也可以包含硬件部分.
对于以上的概念有一个比较清楚的认识之后,就可以在软件的开发过程中进行应用.理论和实践是缺一不可的,相辅相成的.没有理论的指导,实践就缺乏基础；没有实践的证明,理论就缺乏依据,所以呢我一直认为：对于当代的程序员,在有一定的实践基础后,必须学习更深的理论知识.无论你是从那方面先开始学习的.
在软件的开发过程中,从许多过程实践和方法中,大致可以提炼出五大步骤：需求、分析、设计、编码、测试.而体系结构是软件的骨架,是最重要的基础.体系结构是涉及到每一步骤中.一般在获取需要的同时,就应该开始分析软件的体系结构.体系结构现在一般是各个大的功能模块组合成,然后描述各个部分的关系.
我一般认为框架是体系结构中每个模块中更细小的结构.如需要表示web技术,就会用到MVC框架,而web功能只是整个软件体系中的一个功能模块.每个框架可以有许多个实例,如用java实现的MVC框架structs.
而在框架之下就是设计模式,设计模式一般是应用中框架之中的,也可以说是对框架的补充.因为框架只是提供了一个环境,需要我们我里面填入更多的东西.无论是否应用了设计模式,你都可以实现软件的功能,而正确应用了设计模式,是我们对前人软件的设计或实现方法的一种继承,从而让你的软件更软.
打个比方：如果我们准备建一个房子,那房子如果按功能来分：墙壁、地板、照明等,它是按那种样式来组成的,房子是四方的还是圆形的等,这样就组成了房子的体系结构.在体系结构之下,我们可以把框架应用在每个模块中,例如墙壁,我们准备应用什么框架.墙壁可以包括：窗户、门等.窗户和门的组成的就是一种框架.而窗户是什么形状的或者是大还是小,是要为了实现屋内的亮度的,所以呢挑选什么样的窗户就是设计模式.
oracle的架构图如下：
sql server中是用户架构分离：架构不再等效于数据库用户；现在,每个架构都是独立于创建它的数据库用户存在的不同命名空间.也就是说,架构只是对象的容器.任何用户都可以拥有架构,并且架构所有权可以转移.
架构的所有权和架构范围内的安全对象可以转移.有关详细信息,请参阅?ALTER AUTHORIZATION (Transact-SQL).
对象可以在架构之间移动.有关详细信息,请参阅?ALTER SCHEMA (Transact-SQL).
单个架构可以包含由多个数据库用户拥有的对象.
多个数据库用户可以共享单个默认架构.
与早期版本相比,对架构及架构中包含的安全对象的权限的管理更加精细.有关详细信息,请参阅?GRANT 架构权限 (Transact-SQL)?和?GRANT 对象权限 (Transact-SQL).
架构可以由任何数据库主体拥有.这包括角色和应用程序角色.
可以删除数据库用户而不删除相应架构中的对象.
如果为 SQL Server 早期版本编写的代码假定架构等效于数据库用户,这些代码可能会返回错误的结果.
为 SQL Server 早期版本设计的目录视图可能会返回错误的结果.这包括 sysobjects.
在创建数据库对象时,如果您将某一有效的域主体（用户或组）指定为对象所有者,则该域主体将作为架构添加到数据库中.这个新架构将为该域主体所拥有.