Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2981217
  • 博文数量: 412
  • 博客积分: 3010
  • 博客等级: 中校
  • 技术积分: 7374
  • 用 户 组: 普通用户
  • 注册时间: 2009-04-25 15:15
个人简介

学习是一种信仰。

文章分类

全部博文(412)

文章存档

2014年(108)

2013年(250)

2010年(11)

2009年(43)

我的朋友

分类: 数据库开发技术

2009-05-29 18:16:55

8 数据库与模式(Schemas)

SQL标准明确了SQL模式(SQL schema)的定义,然而,许多数据库对它的实现并不正确。SQL模式是指一个数据库内部的名字空间,此空间内部的对象可以通过成员操作符.访问。

一个完整名字的查询类似这种形式:select * from database.schema.table

The SQL specification makes clear what an "SQL schema" is; however, different databases implement it wrongly. To compound this confusion the functionality can, when wrongly implemented, overlap with that of the parent-database. An SQL schema is simply a namespace within a database, things within this namespace are addressed using the member operator dot ".". This seems to be a universal amongst all of the implementations.

A true fully (database, schema, and table) qualified query is exemplified as such:select * from database.schema.table

Now, the issue, both a schema and a database can be used to isolate one table, "foo" from another like named table "foo". The following is pseudo code:

*  select * from db1.foo vs. select * from db2.foo (no explicit schema between db and table)

*  select * from [db1.]default.foo vs. select * from [db1.]alternate.foo (no explicit db prefix)

The problem that arises is that former MySQL users will mistakenly create multiple databases for one project. In this context MySQL databases are analogous in function to Postgres-schemas, insomuch as Postgres lacks off-the-shelf cross-database functionality that MySQL has. Conversely, Postgres has rightfully applied more of the specification, in a sane-bottom-up approach, implementing cross-table, cross-schema, and then left room for future cross-database functionality.

MySQL aliases behind the scenes, schema with database, such that create schema, and create database are analogs. It can be said, that MySQL therefore, has implemented cross-table functionality, skipped schema functionality entirely and provided similar functionality into their implementation of a database. In summary, Postgres fully supports schemas, but lacks some functionality MySQL has with databases, while MySQL doesn't even attempt to support true schemas.

The end result is spin from both communities. While the Postgres community maintains that one database is all that is needed for one project; and MySQL, that schemas have no legitimate purpose when the functionality can be achieved with databases. Postgres adheres to more of the SQL specification, in a more intuitive fashion (bottom-up), while MySQL's pragmatic counterargument allows their users to get the job done without any major drawback.

9 外部连接

*  ,包括Oracle, DB2, Microsoft SQL Server, MySQL PostgreSQL. (08/Jun/2007)

*  . (14/Mar/2005)

*  . (2004)

*  (29/Sep/2003)

*  (Mar/2005)

*  PostgreSQL vs. MySQL vs. Commercial Databases: It's All About What You Need (12/Apr/2004)

* 

阅读(1290) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~