informix有跟其他数据库一样的schema的概念么

Informix在1980年成立，目的是为Unix等开放 *** 作系统提供专业的关系型数据库产品。公司的名称Informix便是取自Information和Unix的结合。Informix第一个真正支持SQL语言的关系数据库产品是InformixSE（StandardEngine）。InformixSE的特点是简单、轻便、适应性强。它的装机量非常之大，尤其是在当时的微机Unix环境下，成为主要的数据库产品。它也是第一个被移植到Linux上的商业数据库产品。在90年代初，联机事务处理成为关系数据库越来越主要的应用，同时，Client/Server结构日渐兴起。为了满足基于Client/Server环境下联机事务处理的需要，Informix在其数据库产品中引入了Client/Server的概念，将应用对数据库的请求与数据库对请求的处理分割开来，推出了Informix-OnLine，OnLine的一个特点是数据的管理的重大改变，即数据表不再是单个的文件，而是数据库空间和逻辑设备。逻辑设备不仅可以建立在文件系统之上，还可以是硬盘的分区和裸设备。由此提高了数据的安全性。1993年，为了克服多进程系统性能的局限性，Informix使用多线程机制重新改写数据库核心，次年初，Informix推出了采用被称为"动态可伸缩结构"（DSA）的InformixDynamicServer。除了应用线程机制以外，Informix在数据库核心中引入了虚处理器的概念，每个虚处理器就是一个Informix数据库服务器进程。在DynamicServer中，多条线程可以在虚处理器缓冲池中并行执行，而每个虚处理机又被实际的多处理机调度执行。更重要的是：为了执行高效性和多功能的调谐，Informix将虚处理器根据不同的处理任务进行了分类。每一类被优化以完成一种特定的功能。到90年代后期，随着Internet的兴起，电子文档、、视频、空间信息、Internet/Web等应用潮水般涌入IT行业，而关系数据库所管理的数据类型仍停留在数字、字符串、日期等六七十年代的水平上，其处理能力便显得力不从心了。1992年，著名的数据库学者、Ingres的创始人加州大学伯克利分校的MichaelStonebraker教授提出对象关系数据库模型，从而找到了一条解决问题的有效途径。1995年，Stonebraker及其研发组织的加入了Informix，使之在数据库发展方向上有了一个新的突破：1996年Informix推出了通用数据选件（UniversalDataOption）。这是一个对象关系模型的数据库服务器；它与其他厂商中间件的解决方案不同，从关系数据库服务器内部的各个环节对数据库进行面向对象的扩充；将关系数据库的各种机制抽象化、通用化。UniversalDataOption采用了DynamicServer的所有底层技术，如DSA结构和并行处理，同时允许用户在数据库中建立复杂的数据类型及用户自定义的数据类型，同时可对这些数据类型定义各种 *** 作和运算以实现对象的封装。在定义 *** 作和运算时可以采用数据库过程语言、C语言，它们经注册后成为服务器的一部分。1999年，Informix进一步将UniversalDataOption进行了优化，为用户自定义数据类型和 *** 作过程提供了完整的工具环境。同时在传统事务处理的性能超过了以往的DynamicServer。新的数据库核心便被命名为IDS2000。它的目标定位于下世纪基于Internet的复杂数据库应用。事实上，Internet的普及从Web开始。Web应用以简便和图文并茂见长。但充斥整个系统的HTML文件又将我们不知不觉地带回了文件系统的时代。采用数据库管理Internet信息遇到的第一个挑战就是复杂信息的管理问题，Internet的出现将"数据"的概念在实际应用中扩大了。为此，自1995年起，Informix便着手进行新一代数据库系统的设计。作为专业的数据库厂商，Informix首先针对Internet应用中数据类型的多样化，采用对象技术对关系数据库体系进行了扩展。与众不同之处在于，Informix并非将新的数据类型写死在数据库核心中，而是将数据库系统中各个环节充分地抽象化，使用户有能力定义和描述自己需要管理的数据类型，将可管理的数据类型扩展到无限，同时适应了未来应用发展的需要。这就是Informix今年新推出的数据库服务器--InformixDynamicServer2000（简称IDS2000）。在IDS2000中，Informix的另一重大贡献在于抽象化数据库的访问方法（索引机制和查询优化）并将其中接口开放。这样，用户便可以自己定义对复杂对象的全新的索引机制，并融入整个数据库服务器。在IDS2000中，所有用户自定义的数据类型、 *** 作、索引机制都将被系统与其内置的类型、 *** 作和索引机制同等对待。IDS2000将所有数据库 *** 作纳入标准数据库SQL的范畴，在形式上与传统关系数据库完全兼容，但适应了"数据"概念拓展的需求，成为真正的通用数据库。Informix在IDS2000之上增加了一系列核心扩展模块，构成了面向Internet的多功能数据库服务器InformixInternetFoundation2000。INFORMIX主要产品分为三大部分：数据库服务器(数据库核心)应用开发工具网络数据库互联产品数据库服务器有两种，作用都是提供数据 *** 作和管理：SE：完全基于UNIX *** 作系统，主要针对非多媒体的较少用户数的应用ONLINE：针对大量用户的联机事务处理和多媒体应用环境应用开发工具是用以开发应用程序必要的环境和工具，主要也有两个系列：4GL：INFORMIX传统的基于字符界面的开发工具，该系列的主要产品有五个，他们是I-SQL、4GLRDS、4GLCCOMPILER、4GLID和ESQL/C；NewEra：INFORMIX最新提供的具有事件驱动能力、面向对象的基于各种图形界面的开发工具。INFORMIX的网络数据库互联产品：提供给用户基于多种工业标准的应用程序接口，通过它可以和其它遵守这些工业标准的数据库联接。

一、区别：

1、在MySQL中创建一个Schema好像就跟创建一个Database是一样的效果，

1、在SQL Server和Orcal数据库中好像又不一样 目前我只能理解，在mysql中 schema<==>database。

二、数据库中User和Schema的关系：

User就是每个Schema的主人，（所以Schema包含的是Object，而不是User），其实User是对应与数据库的（即User是每个对应

数据库的主人），既然有 *** 作数据库（仓库）的权利，就肯定有 *** 作数据库中每个Schema（房间）的权利，就是说每个数据库映射的User有每个

Schema（房间）的钥匙，换句话说，如果他是某个仓库的主人，那么这个仓库的使用权和仓库中的所有东西都是他的（包括房间），他有完全的 *** 作权，可以

扔掉不用的东西从每个房间，也可以放置一些有用的东西到某一个房间，呵呵，和现实也太相似了吧。我还可以给User分配具体的权限，也就是他到某一个房间

能做些什么，是只能看（Read-Only），还是可以像主人一样有所有的控制权（R/W），这个就要看这个User所对应的角色Role了，至于分配权

限的问题，我留在以后单独的blog中详述。比喻到这里，相信大家都清楚了吧。

在SQL Server2000中，假如我们在某一个数据库中创建了用户Bosco，按么此时后台也为我们默认地创建了默认Schema Bosco。Schema的名字和User的名字相同，这也是我们分不清楚用户和Schema的原因。

在SQL Server2005中，为了向后兼容，当你用sp_adduser 存储过程创建一个用户的时候，SQL

Server2005同时也创建了一个和用户名相同的Schema，然而这个存储过程是为了向后兼容才保留的，我们应该逐渐熟悉用新的DDL语言

Create User和Create Schema来 *** 作数据库。在SQL Server2005中，当我们用Create

User创建数据库用户时，我们可以为该用户指定一个已经存在的Schema作为默认Schema，如果我们不指定，则该用户所默认的Schema即为

dbo Schema，dbo 。

房间（Schema）好比一个大的公共房间，在当前登录用户没有默认Schema的前提下，如果你在大仓库中进行一些 *** 作，比如Create

Tabe，如果没有指定特定的房间（Schema），那么你的物品就只好放进公共的dbo房间（Schema）了。但是如果当前登录用户有默认的

Schema，那么所做的一切 *** 作都是在默认Schema上进行（比如当前登录用户为login1，该用户的默认Schema为login1，那么所做的

所有 *** 作都是在这个login1默认Schema上进行的。实验已经证明的确如此）。估计此时你会有一点晕，为什么呢？我刚才说dbo是一个

Schema，但是你可以在数据库中查看到，dbo同时也是一个user，晕了吧，呵呵。

在SQL Server2005中创建一个数据库的时候，会有一些Schema包括进去，被包括进去的Schema有：dbo，INFORMATION_SCHEMA, guest，sys等等（还有一些角色Schema，不提了，有晕了）。

上文中已经提到了，在SQL Server2005中当用存储过程sp_adduser创建一个user时，同时SQL

Server2005也为我们创建了一个默认的和用户名相同的Schema，这个时候问题出来了，当我们create table

A时，如果没有特定的Schema做前缀，这个A表创建在了哪个Schema上，即进入了哪个房间？答案是：

1如果当前 *** 作数据库的用户（可以用Select current_user查出来）有默认的Schema（在创建用户的时候指定了），那么表A被创建在了默认的Schema上。

2如果当前 *** 作数据库的用户没有默认的Schema（即在创建User的时候默认为空），但是有一个和用户名同名的Schema，那么表A照样被创建

在了dbo

Schema上，即使有一个和用户名同名的Schema存在，由于它不是该用户默认的Schema，所以创建表的时候是不会考虑的，当作一般的

Schema来处理，别看名字相同，可是没有任何关系哦。

3如果在创建表A的时候指定了特定的Schema做前缀，则表A被创建在了指定的 Schema上（有权限吗？）

现在问题又出来了，在当前 *** 作数据库的用户（用select

current_user可以查看到，再次强调）没有默认Schema的前提下，当我们用Create table A语句时，A表会去寻找dbo

Schema，并试图创建在dbo Schema上，但是如果创建A表的用户只有对dbo

Schema的只读权限，而没有写的权限呢？这个时候A表既不是建立不成功，这个就是我以后会提及到的Login,User,

Role和Schema四者之间的关系。在这里，为了避免混淆和提高 *** 作数据库的速度（在少量数据范围内，对我们肉眼来说几乎看不到差异），我们最好每次

在 *** 作数据库对象的时候都显式地指定特定的Schema最为前缀。

现在如果登录的用户为Sue，该用户有一个默认Schema也为Sue，那么如果现在有一条查询语句为Select from mytable, 那么搜寻每个房间（Schema）的顺序是怎样的呢？顺序如下：

1 首先搜寻sysmytable （Sys Schema）

2 然后搜寻Suemytable (Default Schema)

3 最后搜寻 dbomytable (Dbo Schema)

执行的顺序大家既然清楚了，那么以后在查询数据库表中的数据时，最好指定特定的Schema前缀，这样子，数据库就不用去扫描Sys Schema了，当然可以提高查询的速度了。

另外需要提示一下的是，每个数据库在创建后，有4个Schema是必须的（删都删不掉），这4个Schema为：dbo，guest，sys和INFORMATION_SCHEMA，其余的Schema都可以删除。

数据库CatalogSchema概念解读

按照SQL标准的解释，在SQL环境下Catalog和Schema都属于抽象概念，可以把它们理解为一个容器或者数据库对象命名空间中的一个层次，主要用来解决命名冲突问题。从概念上说，一个数据库系统包含多个Catalog，每个Catalog又包含多个Schema，而每个Schema又包含多个数据库对象（表、视图、字段等），反过来讲一个数据库对象必然属于一个Schema，而该Schema又必然属于一个Catalog，这样我们就可以得到该数据库对象的完全限定名称从而解决命名冲突的问题了；例如数据库对象表的完全限定名称就可以表示为：Catalog名称Schema名称表名称。

详细信息如下：

InOracle:

serverinstance==database==catalog:alldatamanagedbysameexecutionengine

schema:namespacewithindatabase,identicaltouseraount

user==schemaowner==namedaount:identicaltoschema,whocanconnecttodatabase,whoownstheschemaanduseobjectspossiblyinotherschemas

toidentifyanyobjectinrunningserver,youneed(schemanameobjectname)

InPostgreSQL:

serverinstance==dbcluster:alldatamanagedbysameexecutionengine

database==catalog:singledatabasewithindbcluster,isolatedfromotherdatabasesinsamedbcluster

schema:namespacewithindatabaseItallowsmanyuserstouseonedatabasewithoutinterferingwitheachother

user==namedaount:whocanconnecttodatabase,ownanduseobjectsineachalloweddatabaseseparately

toidentifyanyobjectinrunningserver,youneed(databasenameschemanameobjectname)

InMySQL:

serverinstance==notidentifiedwithcatalog,justasetofdatabases

database==schema==catalog:anamespacewithintheserver

user==namedaount:whocanconnecttoserveranduse(butcannotown-noconceptofownership)objectsinoneormoredatabases

toidentifyanyobjectinrunningserver,youneed(databasename

在SQL标准中，Database和Schema是不同的概念，在很多数据库中，二者也有明显的不同，但在另外一些数据库中，二者可能是相同的含义。

通常情况下，Database指的是一个数据库中的一类对象，用于组织表、视图、存储过程、自定义函数等数据库对象；而Schema除了包含对象外，另外一个重要的特点是有用户的概念，可以这样理解Schema：Schema是指定的数据库用户和这个用户所拥有的所有数据库对象的集合。

以上就是关于informix有跟其他数据库一样的schema的概念么全部的内容，包括:informix有跟其他数据库一样的schema的概念么、数据库中Schema和Database有什么区别、在数据库中CatalogSchema指的是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！