sqlserver中架构,sqlserver 架构

sql server2005数据库中使用架构

引用帮助文档对架构的定义： 从 SQL Server 2005 开始，每个对象都属于一个数据库架构。数据库架构是一个独立于数据库用户的非重复命名空间。您可以将架构视为对象的容器。可以在数据库中创建和更改架构，并且可以授予用户访问架构的权限。任何用户都可以拥有架构，并且架构所有权可以转移。 在SQL Server 2000中架构和用户是没有多大的区别，我们在2000中一般是指所有者。2005后，用户和架构开始明确的分开，架构可以理解为对象的容器或者命名空间。 对于架构特点的理解小节如下： 1.一个架构中不能包含相同名称的对象，相同名称的对象可以在不同的架构中存在。 2.一个架构只能有一个所有者，所有者可以是用户, 数据库角色, 应用程序角色。 3.一个用数据库角色可以可以拥有一个默认架构，和多个架构。 4.多个数据库用户可以共享单个默认架构。 5.由于架构与用户独立，删除用户不会删除架构中的对象。 6.SQL Server 2000 中对象引用是： [DatabaseServer].[DatabaseName].[ObjectOwner].[DatabaseObject] SQL Server 2005 中对象引用是： [DatabaseServer].[DatabaseName].[DatabaseSchema].[DatabaseObject]

目前创新互联建站已为上1000+的企业提供了网站建设、域名、网站空间、网站托管、服务器托管、企业网站设计、阿图什网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。

sql server中的架构是什么意思?

在sqlserver 2005中，可能大家在工作或学习的时候会经常发现这样一些问题，你使用一个账户在数据库中创建了一张表，却发现你自己创建的表却没有修改和查询的权限，这是一件很郁闷的事情，在sqlserver2000中却不存在这样的问题，那为什么在2005中会出现这样的事情，这样的设置可以带来哪些好处？其实导致这一问题的原因主要在于2005中多了一个新的概念—架构。

首先我们来看一下msdn中对架构的定义:架构(Schema)是形成单个命名空间的数据库实体的集合。命名空间是一个集合，其中每个元素的名称都是唯一的。在这里，我们可以将架构看成一个存放数据库中对象的一个容器。

架构实际上在sqlserver2000中就已经存在，当我们使用查询分析器去查询一个表的时候，一个完整的表的名称应该包括服务器名.数据库名.用户名.对象名，而在sqlserver2005中一个表的完全限定名称应该为服务器名.数据库名.架构名.对象名

在2000中，假如有一个账户tt在test数据库中创建了一张表table1的时候，在服务器上对查询的语句应为select * from test.tt.table1,也就是说，在sqlserver 2000中一张表所属的架构默认就是表的创建者的登录名称，用户可以和修改他所创建的所有数据库对象。但在2005中已经将用户和其创建对象所属架构的关联取消了，而加入了一个全新的架构体系，这样做的优点主要在于下面几个方面：

1. 多个用户可以通过角色（role）或组（Windows groups）成员关系拥有同一个架构。

2. 删除数据库用户变得极为简单。

3. 共享缺省架构使得开发人员可以为特定的应用程序创建特定的架构来存放对象，这比仅使用管理员架构（DBO schema）要好。

4. 在架构和架构所包含的对象上设置权限（permissions）比以前的版本拥有更高的可管理性。

5. 区分不同业务处理需要的对象，例如，我们可以把公共的表设置成pub的架构，把销售相关的设置为sales，这样管理和访问起来更容易.

sql server 中创建架构，架构是干什么用的，为什么要创建架构，有什么好处？

SQL Server 中的 架构 ( schema )

与 软件构架 与 架构师 的不是同一个概念

schema 是用于 在一个 大项目中的 各个 小项目

每个 小项目的表, 放在 各自的 schema 下面.

这样, 遇到 小项目里面. 有 相同名字的 表的话, 不会发生冲突.

例如一个 公司的 系统.

里面分2个 子系统, 分别为 财务系统 和 人力资源系统.

这2个 子系统, 共用一个数据库

.

那么 财务系统的表, 可以放在 财务的 schema.

人力资源系统的表，放在 人力资源系统的模式里面。

这2个 子系统， 能够 互相访问 对方的表

但是又不因为 表重名 的问题，影响对方。

体系结构是下面这个样子的

[服务器名称].[数据库名称].[构架名称].[表名]

create database -- 创建一个数据库

create schema -- 创建一个构架

当你在 SQL Server 里面， 使用 create database 创建一个数据库以后。

你可以不必额外的去创建 schema

因为 SQL Server 会 自动的创建一个 名字叫 dbo 的 schema

sql server中架构是什么意思

架构（Schema）是一组数据库对象的集合，它被单个负责人（可以是用户或角色）所拥有并构成唯一命名空间。你可以将架构看成是对象的容器。

在 SQL Server 2000 中，用户（User）和架构是隐含关联的，即每个用户拥有与其同名的架构。因此要删除一个用户，必须先删除或修改这个用户所拥有的所有数据库对象。

在 SQL Server 2005 中，架构和创建它的数据库用户不再关联，完全限定名（fully-qualified name）现在包含4个部分：server.database.schema.object

1. 体系结构（Architecture）

体系结构亦可称为架构，所谓软件架构，根据Perry 和Wolfe之定义：Software Architecture = {Elements,Forms, Rationale / Constraint }，也就是软件主架构 = {组件元素，元素互助合作之模式，基础要求与限制}。Philippe Kruchten采用上面的定义，并说明主架构之设计就是：将各组件元素以某些理想的合作模式组织起来，以达成系统的基本功能和限制。体系结构又分为多种样式，如Pipes and Filters等。

2. 框架(Framework)

框架亦可称为应用架构，框架的一般定义就是：在特定领域基于体系结构的可重用的设计。也可以认为框架是体系结构在特定领域下的应用。框架比较出名的例子就是MVC。

3. 库(Library)

库应该是可重用的、相互协作的资源的集合，供开发人员进行重复调用。它与框架的主要区别在于运行时与程序的调用关系。库是被程序调用，而框架则调用程序。比较好的库有JDK。

4. 设计模式（Design Pattern）

设计模式大家应该很熟悉，尤其四人帮所写的书更是家喻户晓。“四人帮”将模式描述为“在一定的环境中解决某一问题的方案”。这三个事物 — 问题、解决方案和环境 — 是模式的基本要素。给模式一个名称，考虑使用模式将产生的结果和提供一个或多个示例，对于说明模式也都是有用的。

5. 平台（PlatForm）

由多种系统构成，其中也可以包含硬件部分。

对于以上的概念有一个比较清楚的认识之后，就可以在软件的开发过程中进行应用。理论和实践是缺一不可的，相辅相成的。没有理论的指导，实践就缺乏基础；没有实践的证明，理论就缺乏依据，因此我一直认为：对于当代的程序员，在有一定的实践基础后，必须学习更深的理论知识。无论你是从那方面先开始学习的。

在软件的开发过程中，从许多过程实践和方法中，大致可以提炼出五大步骤：需求、分析、设计、编码、测试。而体系结构是软件的骨架，是最重要的基础。体系结构是涉及到每一步骤中。一般在获取需要的同时，就应该开始分析软件的体系结构。体系结构现在一般是各个大的功能模块组合成，然后描述各个部分的关系。

我一般认为框架是体系结构中每个模块中更细小的结构。如需要表示web技术，就会用到MVC框架，而web功能只是整个软件体系中的一个功能模块。每个框架可以有许多个实例，如用java实现的MVC框架structs。

而在框架之下就是设计模式，设计模式一般是应用中框架之中的，也可以说是对框架的补充。因为框架只是提供了一个环境，需要我们我里面填入更多的东西。无论是否应用了设计模式，你都可以实现软件的功能，而正确应用了设计模式，是我们对前人软件的设计或实现方法的一种继承，从而让你的软件更软。

体系结构是可以从不同视角来进行分析的，所以软件体系结构的设计可以按照不同的视角来进行的。按4+1 views的论述，那是四种views：逻辑、开发、过程、物理和场景。因此体系结构是逐渐细化的，你不可能开始就拿出一个完美的体系结构，而只能根据开发过程逐渐对体系结构进行细化。

打个比方：如果我们准备建一个房子，那房子如果按功能来分：墙壁、地板、照明等，它是按那种样式来组成的，房子是四方的还是圆形的等，这样就组成了房子的体系结构。在体系结构之下，我们可以把框架应用在每个模块中，例如墙壁，我们准备应用什么框架。墙壁可以包括：窗户、门等。窗户和门的组成的就是一种框架。而窗户是什么形状的或者是大还是小，是要为了实现屋内的亮度的，因此挑选什么样的窗户就是设计模式。

oracle与sql server在架构处理上有何区别

oracle的架构图如下：

sql server中是用户架构分离：架构不再等效于数据库用户；现在，每个架构都是独立于创建它的数据库用户存在的不同命名空间。也就是说，架构只是对象的容器。任何用户都可以拥有架构，并且架构所有权可以转移。

架构的所有权和架构范围内的安全对象可以转移。有关详细信息，请参阅 ALTER AUTHORIZATION (Transact-SQL)。

对象可以在架构之间移动。有关详细信息，请参阅 ALTER SCHEMA (Transact-SQL)。

单个架构可以包含由多个数据库用户拥有的对象。

多个数据库用户可以共享单个默认架构。

与早期版本相比，对架构及架构中包含的安全对象的权限的管理更加精细。有关详细信息，请参阅 GRANT 架构权限 (Transact-SQL) 和 GRANT 对象权限 (Transact-SQL)。

架构可以由任何数据库主体拥有。这包括角色和应用程序角色。

可以删除数据库用户而不删除相应架构中的对象。

如果为 SQL Server 早期版本编写的代码假定架构等效于数据库用户，这些代码可能会返回错误的结果。

为 SQL Server 早期版本设计的目录视图可能会返回错误的结果。这包括 sysobjects。

在创建数据库对象时，如果您将某一有效的域主体（用户或组）指定为对象所有者，则该域主体将作为架构添加到数据库中。这个新架构将为该域主体所拥有。