存储过程和SQL语句比较

做为SQL存储过程和.NET的新手，下面的指导还是很有用的，自己这一段刚刚接触这些东西，搜集了一些相关的东西，能使新手较容易上手，当然啦，要精通和熟练应用，还是要看更多更深的资料的，高手请不要见笑。
以下内容均来自网络，只供参考学习：
--------
存储过程与SQL语句的恩怨情仇 
程序员说：存储过程还是SQL语句，这是一个问题。
江 湖现在有三个流派，一个是SQL语句流的，崇尚使用SQL语句，一派是存储过程派的，崇尚用存储过程说话，还有一派是中庸派的，讲求和谐，所以也就前两派 吵得厉害，中庸派的看热闹。现在SQL派的有Nhibernate为首的众多ORM助阵，最近风生水起比较得意，存储过程派也有自己的杀手秘籍，两派互不 相让，争斗由来已久。
存储过程派的追求速度，所谓天下无功无坚不破，唯快不破，这也是存储过程派的人行走江湖的最大本钱。之前存储过程派的攻击SQL语句派的还有一个秘籍就是安全，不过现在都没人用连接String的动态SQL的了，这招也就失效了。
SQL语句派是资格很老的流派，但是新手居多，老资格很多投奔敌营存储过程派了。Java帮的人很多都是SQL语句派的，而存储过程派的以微软帮的居多。
不 过存储过程派也有软肋，可移植性就是其一，还有一点就是可扩展性，因为一般大型的Web应用程序都是多Web服务器，然后用双数据库服务器做双机热备，其 中一台开机，但是是闲置的，这里只是解决单点故障的问题，但是形成了多Web应用服务器，单数据库服务器的情况，如果所有的运算都用存储过程实现，那么会 造成数据库服务器负担过重，而Web服务器负荷不足的情况，而扩展数据库服务器的话就会非常的麻烦，而且投资较大，程序也需要改，而投资Web服务器就相 对便宜而且扩容更加简单。
人在江湖漂哪有不挨刀，所以中庸一点比较保险，我比较倾向于用把较多的负担放到程序里来，而降低数据库得负担，因为只要 数据库扛得住，再增加Web服务器那是比较容易的，但是一旦数据库服务器扛不住了我们就只有哭了。一般报表阿，还有一些结果集比较复杂的我就用存储过程来 包装，一般的查询和CUID操作我都是找个ORM来搞定。

其实主要是在说存储过程的软肋。
1）从部署上看，存储过程要比sql难 
2) 从性能看，存储过程要比SQL高 
3) 从安全性将，存储过程比SQL防注入
过程可以减少网络数据传输量，把计算都放在服务器上   
    
前端程序可以直接访问数据库的表，可以直接用SQL语言直接对数据库的表进行读写操作；   
    
 为安全，可以编程，使用存储过程进行数据表的读写操作，而前端程序直接访问这些存储过程，而不是数据库的表；   
    
更安全的方法是：在前端程序和数据库之间，增加数据库访问层；前端将数据的读写请求提交给中间层，有中间层与数据库连接进行数据库的实际操作，将结果送给前端，这种方式可以避免前端机器直接连接到数据库的可能，数据库更安全。