用核桃夹当锤子来砸核桃，当然也是可以的

        基于oracle的应用的解决方案，不是一个dba和几个只懂得增删改查的开发人员就可以设计好的。
        狭义的dba主要搭建和恢复，开发人员才主要在应用。否则，设计的结果，要么没根本没有任何的oracle的优势/也必然有很多隐含的问题。所以说开发小组的人员必须有精通数据库的开发人员，才能保证数据库的逻辑/应用是可靠的。

        很多“架构师”说我的系统不但支持oracle/sqlserver/db2/mysql，而且不但支持千万数据，还支持上亿数据；而这所有的一切都是通过参数配置，就可以用一套系统来实现,很牛吧。但是这样的产品十之八九对数据库访问常常是通过最简单最基础的sql进行实现，而这样将无法使用各种数据库的优势，效率很低。对于数据库操作，几十万和几千万的最佳解决方案往往是不一样的，而不同数据库的解决方案，则更是不一样。这些问题常常是普通增删改的测试无法测出的，如：多用户并行产生的排序不一致；长事务提交、oltp下的位图索引等引起的锁；索引冲突等等。可以说对于针对上亿数据作出的oracle的高效应用，在执行效率上一般至少要那种大而全的系统快速50倍甚至上百倍以上。几个只懂得增删改查的开发人员开发完毕，然后找DBA优化是很难开发出高效的海量数据库系统的，因为数据库的大部分性能问题，都集中在应用开发中。

        但是情况常常是很多系统开发出来的后，开发人说数据库太慢了，再找个DBA优化下数据库。但是从经验看很多的性能问题，都是出现在应用上，不是实例级的优化可以解决的。有人说，oracle是数据库no1，不用了解，他自己会把事情干好。不是的，他也许是数据库no1，但很多时候他不是很智能的，唯一联合索引的第一个字段如果和近乎唯一索引的使用普通索引的单一字段同时作为查询条件时，也许是你改使用强制索引失效的方式，来改变oracle默认执行计划的时候了；小于4k的默认存储。所以oracle只是针对大多数应用进行解决，而不是所有应用。只有针对当前业务，设计出来的东西，才可能是最好的东西。而这个东西对于默认方式，很可能改动很多，其中绝大部分不是数据库本身的调整，而是应用的调整。

        很多人看个概念，轻轻测试下，就应用到大型系统中。一般是有问题的。（版本/应用环境/应用的特殊性）不过，非要用核桃夹当锤子来砸核桃，当然也是可以的。