将Mysql、PostgreSQL二个开源数据库和Oracle放在一起对比，多少显得有些不公平，后者是有强大厂商及上千技术人员支持和维护的商用数据库，而前者是开源和免费的产品。但是，这种对比，有助于我们在架构自己的业务和应用时，做出理性的选择。
随着现代数据库可用特征集的迅速增加，很难区分孰好孰坏。例如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事件触发器。就我个人而言，除非万不得已我不会使用触发器。因为他们常常被忘记，有时反而给你添乱。少量使用的话，效果反而会很好。

安全性
所有这三个数据库都有它的脆弱性。软件肯 定有一些死角故障隐藏其中，这是它的本性。此外，这三个数据库都会定期发布更新包。然而我个人的感觉是，开源意味着必然有更多的目光，并且经常更多的是挑 剔的目光盯在程序上面。而且在开源世界里社区施加的压力要大得多。在商界，当修理费用远远高于等待补丁的费用时，厂家可以并且经常会耍手段。
在数据库内部的安全性方面，所有这三个数据库都支持口令登录和数据库内部各种类型的加密。Oracle确有一种新特征叫做虚拟专用数据库，其中 表的段和列都可以被编码，对于视图是隐藏的。这对于一些有争议的或是敏感的数据非常有用，DBA和其他管理员对这些数据是无权访问的。

结论
　　很明显，这三个数据库平台都有大量的特征，对于同一问题也有不同的解决方案。就安全性，触发器，视图，物化图和存储过程而言，他们提供了许 多一样的功能，尽管在性能和配置方面有些差异。在第二部分，我们将讨论数据库真正开始千差万别的一些方式，从索引方面，可能最重要的是从它们的优化引擎方 面。
　　在前面对数据库的比较中，我们提到了几种不同的特征，比如触发器，视图和存储过程。虽然在Oracle，Postgresql和MySQL中这几个特征集彼此之间有所不同，但是你遇到的大部分应用都是集中在这几个方面。这一次，我们将讨论这几个平台之间存在明显差异的一些东西，最重要在于它们处理SQL复合语句和优化选择的方式上。

SQL复合语句（优化引擎）
　　不管你选择哪个数据库，SQL语言都是你和数据库交互的最基本和最重要的方式。 这也正是这三个平台开始分道扬镳的地方。 Oracle支持大量复杂的查询,几乎是无限多的表和所有类型的联结以及组合。但这些充其量只是冰山一角，Oracle真正的王牌在于它的Cost Based Optimizer（基于代价的优化器），它分析SQL语句，如果可能的话会重写和简化它，基于代价选择索引，根据驱动表和其他一些神秘的方式来做出决定。
　　读一下MySQL的文档你就会发现性能偏见的来源，这些是厂家细节类型，它使得性能优化和性能调节在任何平台上都很复杂。MySQL能够处 理的任何JOIN或者VIEW语句的固定最大值是61张表。 我个人又有点疑问，不管怎么说，应用程序中表太多了处理起来会更困难，所以正如前面所说，确实是优化器而不是能够查询的最大表规格占上风，等等。
　　Postgresql 8.x版支持所有的SQL92规范，几乎没有什么限制。 我再次认为，一种数据库优于其他数据库在于优化程序方面做得好。复合查询很麻烦，所以查询策略就成了你分析性能瓶颈的最好参考。
　　
索引类型
　　索引技术对数据库性能来说是很关键的，Oracle在这方面提供了很多的选择。目前存在着太多的索引类型，从标准的B树到反向键，再到基于 函数的时常误用的位图索引，甚至index-only表。作为附加技术，DBA还可以使用Oracle Text，它提供了索引能够让你查找CLOB（大字符对象），而且Oracle Spatial提供了基于位置数据的索引。
　　在MySQL里，我们发现有B树，哈希表，全文和GIS索引（基于位置数据），还有簇索引，但是如果我在Oracle方面的经验有任何指导 作用的话，我可以说这些跟大多数应用程序都是不相关的。大部分时候，B树索引是我在Oracle，MySQL和Postgres应用中能看到的唯一一种索 引。除此之外，就算作为示例，基于函数的索引在MySQL中也是没有的，但是它们能够靠创建另一列使用那个函数和一些数据来模拟，然后再增加一个触发器使 它更受欢迎。
　　Postgresql提供了B树和哈希表，以及r树和它自己个性化的GiST索引类型，它允许创建用户自定义类型和基于函数的索引。 Oracle也提供了一种类似的函数，其中它的基于函数的索引能够用于基于pl/sql的函数，而不仅仅是标准的系统预定义函数，例如那些你可能不会用到 的trunc，UPPER函数。但是你要小心了，这样的索引很可能访问速度极慢，当它从你的表中输入输出数据的时候，速度慢得你甚至都可以放慢语速加入讨 论了。
再次强调一下，Oracle真正胜出的地方就在于它的实现方式和优化器选择索引的策略上。
Oracle允许你通过审核跟踪设施对表和文件启用审计功能。一旦启用，你可以审计插入，更新或者删除一个特定的表，还可以注册，甚至是某一特定用户对数据库全部的访问。你有相当多的选择权，并且启用很容易。
　　Postgresql也有这个函数，据说跟Oracle的同样灵活、易于配置。
另一方面，MySQL的核心函数中好像不提供这个函数，你当然可以构建自己的存储过程和触发器来做你想做的事情，并把相应的信息填入一张表中，只是相对麻烦一些。