我不是一个 DBA 。我是做程序开发的。当然也是初出茅庐。呵呵。
之前查了下存储过程，大多都是对其的赞美但有一问题：
在应用程序中访问数据库的时候，是否应该优先考虑使用存储过程呢？
如果可以的话，应用中几乎所有的 SQL 都可以用“存储过程”来代替。
看了对存储过程的介绍后，我甚至有将简单的 “单表SELECT” 和 INSERT 语句，等等这些简单的 SQL 都改用存储过程的冲动。
像这样“疯狂”的使用存储过程就没有一些弊端吗？
之前查了下存储过程，大多都是对其的赞美但有一问题：
在应用程序中访问数据库的时候，是否应该优先考虑使用存储过程呢？
如果可以的话，应用中几乎所有的 SQL 都可以用“存储过程”来代替。
看了对存储过程的介绍后，我甚至有将简单的 “单表SELECT” 和 INSERT 语句，等等这些简单的 SQL 都改用存储过程的冲动。
像这样“疯狂”的使用存储过程就没有一些弊端吗？
大量使用存储过程 1移植烦,2更新难,3编写要严谨
“更新难”----我觉得这个很牵强，面对“更新”时， SQL 的更新也不是一件容易的事。会比存储过程强多少呢？
“编写要严谨”......这个无论何时都是必须的。
我的意思是，在应用程序需要访问数据库的时候，以前在应用中用的都是 SQL ，今天简单的认识了一下存储过程，感觉储过程不但在处理复杂的数据处理过程中存在优势，甚至对于简单的数据处理例如：
SELECT column_a FROM table_a WHERE id = 1; 这个简单查询都很有优势，因为对于 SQL 而言需要每次都编译这个语句，但如果把这个语句用存储过程来取代，因为存储过程只需编译一次，所以在运行效率上这简单的查询的效率都会高于 SQL 。
但是不是说存储过程可以滥用呢？即能否，或者说有没有必要将一个简单的查询都写成存储过程呢？
任何数据库都不会每次去“编译”这个语句 sql本身和它的执行计划都在数据库中有缓存 起码能够有PL-SQL语言的数据库都能做到这点相对查询的成本，编译的开销可以忽略，除非是上亿条结构完全一致，数值不一致的语句，但是前面说了，这种语句，只会在第一次执行的时候编译。
一个频繁数据操作的表，经常因为DDL操作被锁定
一个操作是违反事务逻辑的，用自治事务硬塞进去了，造成了数据逻辑错误。
感谢朋友的指点。不过我想说的是，如果我现在要进行数据库访问，可能一些复杂的查询我需要使用存储过程，这种情况没有任何争议。但如果是一个简单的查询为什么通常都会选择 SQL 而不是存储过程。
一个简单的sql，有必要写存储过程吗？存储过程本来就不是为了处理简单的sql而创造出来的，你干嘛背道而驰！
还有你了解存储过程的执行计划吗？谁告诉你存储过程处理sql非常有优势了，
你处理下动态sql试试，用存储过程处理的比拼接好后用sql执行要慢多了！
仁者见仁，智者见智！
而且存储过程都要放到哪？
sql呢？需要放吗？
原因很多，自己觉得必要的原因就有这些了！
感谢你的指点。我不是很熟悉存储过程，但是之前曾看到过“存储过程的运行效率要比 SQL 高”的说法，所以有此一问。在此你提到“还有你了解存储过程的执行计划吗？谁告诉你存储过程处理sql非常有优势了，
你处理下动态sql试试，用存储过程处理的比拼接好后用sql执行要慢多了！”看来我要好好的学习一下存储过程了。
相对存储过程主要是面向执行过程，有利于对程序的封装，就像JAVA的接口。
比如，你要进行很复杂的业务处理，写一条单纯的sql文不行，这个时候，如果你通过java或其他程序来处理的话，可能要访问很多次数据库，然后进行数据整合啊，业务判断啊，等等一系列处理，那么这样的处理过程肯定是很花时间的，这个时候如果利用存储过程，比如把这些数据性的业务处理全部放到存储过程中来做，那么交由服务器来处理，肯定要比程序快的多，而且以后维护这部分东西，也只需要修改这个存储过程就可以，而不需要去修改程序，这样也变的容易维护！
但是如果是很简单的东西，那么把所有的sql都不要了，都放到服务器的存储过程中，也许某天，你的服务器就挂掉了！
所以必须从多方面来考虑，到底应该有那种方式来处理，不能单纯的只考虑能不能实现这一点，这样sql确实没必要了，但是这也是不现实的！