在服务器端的代码中写sql还是使用存储过程？

Question

接手维护一个项目，c#实现，.net框架，Model，Dao，Bussiness分层架构。项目中的DB操作（增删改查）全部用存储过程实现。我可以想到的坏处是：如果更换数据库，则工作量会非常大。接手项目维护，或者参与开发的人都必须掌握对应数据库的存储过程写法。想问下全部用存储过程做有什么好处？stackoverflow上有人给出从安全角度考虑的好处：youhavetograntpermissionsdirectlytotheunderlyingtablesetc(授权级别)withasproc,allthereal-underlyingschemainformationcanbeencapsulated/hiddenaway(SPscanbeencryptedtoo)（使用存储过程可以对底层的数据结构信息做了相对的加密，因为服务器和数据库的通信过程中不会再出现表结构）http://stackoverflow.com/questions/1199886/stored-procedures-vs-no-stored-procedures-security-viewpoint这个好处不是特别有用吧！还有其他的吗？

Answer 1

强调存储过程是上代数据库为王时代的理念，在10年前oracle/sqlserver为主流的年代，通常都比较强调这个，直到今天还留有很大遗存。
目前基于java平台的项目由于强大的orm框架影响，常规已基本都放弃存储过程使用，.net平台由于历史遗留习惯和还缺乏一非常有力（业界统一的）的orm，所以还有很多项目保守旧有理念，以安全、性能等理由提倡由存储过程实现一个数据中间层。
实际的来讲，使用存储过程
优点
性能-极端情况下对性能有一定提升
缺点
缺乏版本管理
调试跟踪不便
单独的分层导致开发、维护成本提高
长时间历史维护后很容易和主体代码脱节
分布不便
总体来说，除非对性能有特殊极端的要求，且数据逻辑极度复杂导致在sql层和代码层面实现有非常大的性能差异（即使这两点其实大部分也都能通过设计解决），否则当前已经没有必要再使用存储过程了。
                            

Answer 2

我觉得还是用sql比较好，好处上面都已经讲到，我就补充点坏处把
全部用存储过程,意味着你把很多在php层面可以处理的业务逻辑都交给数据库来处理，系统访问量很高时，php容易水平扩展，而数据库的扩展比PHP的扩容要麻烦的多，还得解决延迟等系列问题，数据库永远都是瓶颈，尽可能减少它的压力，让它处理最基本简单的增删改查，其他的计算交给php，比如groupby等.