postgre和oracle性能对比,Oracle和MySQL、PostgreSQL特性对比

随着现代数据库可用特征集的迅速增加，很难区分孰好孰坏。例如Oracle里就有许多你可能从来都不需要的高级数据仓库特征。此外也可能有一些其它不可或缺的特征比如ACID事务特性。我们来看一看主要的一些特征，比如存储过程，视图，快照，表数据类型和事务等等。同时我们分析一下Postgresql，MySQL和Oracle这几个数据库，然后找出哪个能够满足你的需求。

存储过程

数据库里的存储应用程序肯定会有它的拥护者和贬低者。在这个问题上我还不清楚自己属于哪一类，所以我尽量对这两个方面都讨论。当你开始在数据库里放置应用程序代码时，你就处于了彻底不可移植的境地。你把应用程序移植到另一个数据库时，那段代码将不得不被重写。但是它对原来数据库的高度专一性意味着它可以利用那个引擎，和那个引擎紧紧捆绑在一起。有时候数据库里的存储代码要明显快得多。在对数据做了修改之后，你不得不更新一百万行的某些数据块。

在存储过程里，数据的读入、操纵和更新是一步完成的。然而你要在中间层应用程序中做同样事情的话，你就不得不通过网络发送数据集，完成数据操纵，然后将它发送回来。这不但使任务的速度变慢，而且竞争同一数据的其他事务有可能不得不等待，因为它需要的数据正处于传送和操纵状态。存储代码也可以用来密封特定的请求，这对简化你整体的应用程序是很重要的。这三个数据库都支持存储过程和函数。Oracle还支持包，或者说是存储过程的集合以及几乎没有人用过的各种面向对象特征的集合。还要说明一点，一个数据库引擎实际上是在存储代码和嵌入在里面的SQL代码之间关联转换。Oracle 9i版本引入了成批绑定技术，所以你能够对许多行进行处理，并且能够一次性更新它们，而不是单个循环迭代。这个特征大幅度改善了性能。

视图

视图基本上是存储查询，正因为如此执行起来才不会过度复杂。然而当用于查询时，他们必然会使查询复杂化。所以很明显，数据库在视图可用之前一定要支持子查询。Oracle很早就已经有视图了。从5.0版本开始，MySQL也已经支持视图。跟Oracle一样，MySQL也支持UPDATEABLE视图，但是有一些限制。Postgres也支持视图和UPDATEABLE视图。更详细的解释见Complex SQL部分。

物化图(快照)

不用说，Oracle对它们支持得非常好。作为一种新事物，物化图(我更喜欢快照这个可视化的术语，有点离题了)是一个周期性更新的副本或者是表的子集。可以把视图看做是查询的一个副本。直到下一次刷新，那个副本是静态的，没从主机那儿更新的。通常要在更新频率和支持它的事务日志(比如索引)的维护之间做一个折衷。名义上，MySQL和Postgresql不支持物化图，然而互联网上有它的实现，可能会满足你的需求，你要是选择此方案的话就另外需要一些支持了。一个存储程序创建物化图，另一个存储过程刷新它。在本质上，一个CREATE TABLE语句就是AS SELECT..的拷贝。

语言集成

如今，基于web的编程应用虽然使用了不同的数据库，却是完全平等的。几乎所有的web编程语言都支持这些数据库类型。Java，PHP，Perl，Python，C#/.NET，等等等等。尽情享受编程的乐趣吧！

触发器

MySQL，Oracle和Postgres都支持INSERT，UPDATE和DELETE操作的BEFORE和AFTER事件触发器。就我个人而言，除非万不得已我不会使用触发器。因为他们常常被忘记，有时反而给你添乱。少量使用的话，效果反而会很好。

所有这三个数据库都有它的脆弱性。软件肯定有一些死角故障隐藏其中，这是它的本性。此外，这三个数据库都会定期发布更新包。然而我个人的感觉是，开源意味着必然有更多的目光，并且经常更多的是挑剔的目光盯在程序上面。而且在开源世界里社区施加的压力要大得多。在商界，当修理费用远远高于等待补丁的费用时，厂家可以并且经常会耍手段。