业务逻辑实现方式的讨论：存储过程 good or bad?
之前国内外都对存储过程的好与坏进行了激烈的争论，以下是一些调查与讨论的链接，有兴趣可以去了解一下：
本文将不讨论这部分内容，更重要的强调什么情况下使用存储过程，什么情况下应该封装在业务类中。
总体的原则：
1、业务逻辑需要进行复杂的判断处理使用业务类实现
2、涉及小数据量（数据行在200条以内）处理判断使用业务类实现
3、涉及批量数据处理使用存储过程实现（如部门人员批量合并，同时批量增加每个人员的岗位变更信息子表）
4、涉及统计分析部分的逻辑通过存储过程来实现
5、如果需要对外提供数据层接口的部分通过存储过程实现，不建议直接开放数据表，至少也要以视图的形式开放（这种情况很少，一般是内部系统间才会使用这种接口，建议少用）
6、需要进行横向扩展的业务使用业务类实现（如：用户认证表只是纵向扩展，只是记录的增加；企业的数量可能的增长就属于横向扩展或者说模块的数量增长也属于横向扩展，涉及数据表的增加部分）
当然在大多数情况下，需要具体情况具体分析，以下只是针对我目前项目情况的分析：
1、只支持Oracle数据库。即Oracle10g及以上版本的数据库。因为是做SAAS服务，所以客户不需要关心数据库，为此产品没有适应多种数据库环境的需求。
2、模块低耦合。如用户认证、注册、具体业务逻辑模块应用等进行物理上的分离，提供的数据库存储及服务都分布在不同的数据库服务器或者实例上。
3、对可扩展性要求比较高，要求可进行多种方式的扩展（如部署方面可以通过横向增加服务器的方式解决高并发的问题，业务方面要求可以适应不断增加的功能模块，以适应企业管理的需要）。
4、对可靠性要求比较高，要求可提供7*24不间断服务。
总结：
通过Web服务器部署业务逻辑层的执行在横向扩展性能方面存在很大的优势。但在某些方面还是存在一些问题，同时也要考验开发人员的水平与代码的质量，对需求变更的适应性及响应的及时性等等方面。Oracle本身提供了一些数据库负载的解决方案，虽然我不是OracleDBA，但Oracle在数据库方面的成就还是非凡的。据我所了解的情况，发现数据库存在瓶颈的时候，除了优化一些SQL语句的执行效率之外，最先要做的就是数据库的读写分离，大大减少对IO资源的压力。在其它方面应该还有一些解决方案，至少之前在电信、电力、税务等大型应用下Oracle数据库本身并没有存在很大的问题（可能是DBA都解决掉了吧）。而在我的经验中大部分出问题的反而是程序本身，一方面是比较难快速的适应需求变更，另一方面是比较难定位问题。后者很大的原因是没有做好单元测试，造成问题定位困难，造成测试跟踪起来太麻烦。
