关于应用提交sql语句与直接调用存储过程的性能比较问题

首先说明，在公司是做的基于C/S结构的开发，但是这里讨论的主要是数据库查询的性能的问题。我们现在的解决方案是这样：基于查询的业务，一点也不写入到应用程序当中，所有的查询，全部都由在数据库端编写存储过程，而应用程序只负责提交参数，并且调用指定存储过程来完成查询。主要的查询功能完成过程便如上。
我所知道的数据查询还有另外一种方法，那便是：由应用程序生成sql语句，然后把这跳sql提交到数据库，然后来让数据库来分析并执行，并返回给应用程序。并且好像现在利用这种方式的完成查询的还不少。几次看robbin的文章，说的是一分钟or平均一秒钟提交140跳sql语句，等等之类。
至少在我看来，在数据库端编写存储过程，由具体业务调用存储过程的方法，远远优于第二种提交sql语句的方法。优点我自己总结了一下几点：
1. 业务更加灵活。任何一个可想到的业务，只需要在一个存储过程当中，多添加一个typ，多添加一个语句便可实现，大不了是多加一个“@typ=’Z’”；
2. 调试更加方便。毕竟是直接已经在数据库之上，调试存储过程并观察返回的结果集或是执行增删改操作直接观察数据库变化，都比把业务写在持久层更方便；
3. 简化持久层的工作。持久层只需要知道，完成某项业务，需要调用某个存储过程即可，编写sql语句的麻烦，拼sql字符串的问题，统统都转移到数据库上去吧。

而关于提交sql语句到数据库再执行这种方式，个人认为最大的弊端在于：每次提交sql
语句到数据库，数据库都会认为这是一条新的sql语句，并且对这条语句进行编译，SQL SERVER 2005还会对其进行查询性能分析（其他的数据库不知道，但应该也会吧？），结果每次执行的时候，这种事情也会占用数据库宝贵的性能资源，尤其是并发查询相当多的时候。但是对于已经写好并且编译通过的存储过程来说，上面所诉的两条“罪状”均不存在。个人认为，采用调用存储过程的方式优势更多，只是没有想明白为什么采用提交sql的方式，现在依然还是用的这么频繁。
今天第一次在javaeye发帖，抛砖主要是为了引玉。小弟学浅，望各位师兄师姐指点。

1、简单查询肯定sql快，提交sql直接进入sql引擎，完事后直接返回；

2、而调用存储过程就要先调用存储过程引擎，再转换到sql引擎，再转回到存储过程引擎，多做了一步无用工；

3、如果是复杂查询，要对数据库进行多个操作，还是存储过程快，因为这时是数据库内部模块的切换，而sql就要多次从外部操作

且不说存储过程的可维护性，可扩展性问题，就说性能。应用缓存可以减少向数据库发送SQL语句，以JavaEye为例，80%的SQL语句由于缓存统统都被节省掉了，只有20%的SQL才真正发送到数据库服务器，这样的性能才能极大提高。

再说你所谓的参数绑定问题，纯粹是你自己不会用PreparedStatement导致的。

他的意思是直接发sql和使用存储过程谁快的问题，而不是使用缓存和直接差数据库谁快的问题