存储过程
有人支持、也有人反对在数据库中保存应用程序代码。在这个问题上我保持基本公正的态度，所以我会试着从双方来讨论。当你开始将应用程序代码放置到数据库中时，你就变得极其不轻便。在你将你的应用转向另一个数据库时，这个代码将会被重写。但是它放置在数据库上意味着它还可以充分利用和紧密连接这个引擎。在某些情况下在数据库中存储代码可以显著的提高速度。比如你在对数据进行了某些策略后需要更新百万行的数据中的绝大部分。
在一个存储过程中数据是在一步中被读取、操纵和更新的。而如果你在应用程序代码的中间层做相同的操作，那么你需要将数据通过网络传送过去，进行操作和将它发送回来。这不只会减慢这一个任务，其它在竞争和它使用的相同的数据的操作很可能就要等待了，因为这个数据处于传送过程中，而且将被执行操作。此外，存储过程的代码可以提供服务对特定的请求进行封装，这对简化你的整个应用程序来说是非常宝贵的。这三个数据库都支持存储过程和函数。Oracle还支持存储过程的包或集合，还包括各种面向对象的功能，这些功能几乎没有人使用过。一个数据库引擎实际上在存储过程和内嵌在那里的SQL代码之间进行上下文切换。在9i中，Oracle推出了批量绑定，这样你就可以对行的大型集合进行操作，并一次就更新整个集合，而不是在每个循环迭代中进行更新。这个功能甚至还可以非常显著的进一步提高性能。
视图
视图是基本的存储查询，正因为如此，它执行起来不是特别复杂。然而在查询中使用视图时，它们必定会使查询更加复杂。所以很明显，使用数据库中的视图之前，要更新子查询。Oracle显然提供视图有段时间了。在MySQL5.0中，也支持视图了。像Oracle一样，MySQL也支持UPDATEABLE视图，不过有些限制。Postgres也支持视图和UPDATEABLE视图。详见复杂SQL那一节。
物化视图(快照)
物化视图在Oracle中默认模式下支持的很好。作为回顾，记住一个物化视图(我更喜欢更加形象的术语“快照”，我离题了)是一个定期更新的拷贝或是一个表的子集。想象一个视图使用它的查询填充一个镜像拷贝。直到下一次刷新，这个拷贝是静态的，不随主本的更新而更新。通常会在更新的频率和支持它的处理日志(很像一个索引)的维护间做个权衡。名义上，MySQL和Postgresql不支持物化视图，但是在网上有这个的实现，它可以满足你的需求，如果你采用这个方法，你还需要一些支持。用一个存储过程创建物化视图，而另一个刷新它。大致上是CREATE TABLE my_copy AS SELECT。。。
语言集成
今天，基于web 的应用程序编程真的是一个平等的世界。几乎所有流行的web 语言都支持所有的数据库类型。Java、PHP、Perl、Python、C#/.NET 等等。这世界让你随心所欲。
触发器
MySQL、Oracle和Postgres都在INSERT、UPDATE和DELETE上支持BEFORE & AFTER事件触发器。我个人偏向于除非绝对必要，不然不使用触发器。它们正在逐渐被遗忘，但有时又会出现给你制造麻烦。不过如果谨慎的使用它们，它们会是很有用的。
安全
所有这三个数据库都有它们的漏洞。软件中有地方隐藏着错误真的是很正常的。而且，这三个数据库都有定期发布的更新补丁。不过我个人觉得，开源意味着必定有更多的眼光，而通常是批评的眼光在看待这个代码。而且，在开源世界里，社会压力要大的多。在商业领域，当修复比所知的等待修复的成本更昂贵的时候，供应商可能、并通常会加快速度。
在数据库中的安全方面，这三个数据库都采用密码登录和在数据库中对各种类型进行加密。Oracle最近提供了一个叫做虚拟专用数据库(virtual private database)的功能，在它里面数据表的某些部分和字段可以被加密，并隐藏起来不被看到。这对于数据库管理员和其他管理员不应该有权限访问的有争议的或敏感数据来说，非常有用。
总结
我们这三个数据库平台很显然有很多功能，和用于相同问题的不同解决方法。在安全、触发器、视图、物化视图和存储过程方面，它们提供了许多相同的功能性，尽管在性能和可配置性方面不尽相同。在第二部分我们将讨论在索引方面这些数据库真正开始显著不同的一些地方，不过可能最重要的是在它们的优化引擎方面。