为什么不使用基于存储过程编程的框架

1.代码可维护性

SQL是结构化查询语言，其主要目的是用来进行查询，业务逻辑和编程不是它的主要任务，如果硬要用SQL完成复杂的业务逻辑编程，其结果就是整个存储过程复杂无比(相对于例如c#等编程语言)，谁见谁头疼。

2.开发效率

很明显，没有比较好的SQL的编程框架。

3.性能难以扩展

当把业务逻辑整合到存储过程中，相对于只吞吐数据的数据库服务器负载增加不小，为何不把业务逻辑的性能消耗放到另外一台机器上呢。当这台业务逻辑服务器负载不能承受时，可以很轻松的继续添加逻辑服务器来分担负载(相对于添加数据库集群，而且数据实时同步又是一个很大的性能消耗)。这样可以做到尽量少的数据服务器去满足尽量多的业务负载。

当然存储过程也有其特有的优点：性能

因为连接和断开数据库服务器对于执行简单的增删改操作来说是一个很大的性能消耗，过于频繁的连接和断开会导致性能消耗严重，当需要批量操作数据时，存储过程的优势体现出来了。所以我的理解就是，只有当进行批量数据处理的时候才使用存储过程。否则存储过程可以退休了。