存储过程(StoreProcedure)与业务逻辑

                                                            存储过程(StoreProcedure)与业务逻辑

事情的由来是这样的，昨天无意在网上看到一篇关于“是否Hibernate可以使用存储过程？”的帖子。后来看到介绍说在最新的Hibernate 3已经支持存储过程了。

想想刚开始做项目的时候，我们当时的项目经理就是把很复杂的逻辑都写在SP中的，其运行效率用飞快来形容一点也不夸张，我承认直到今天我依然对SP有种特殊的感情，毕竟我在后面很多项目中都用到了SP，不管是SQLSERVER的还是ORACLE。

不过一直以来都有一个疑惑埋藏在心里，业务逻辑到底是放到J2EE业务层实现？还是在数据层（存储过程）实现？为这个问题也和同事之间互相讨论过，各有各的看法，有人嫌存储过程写起来麻烦，有人说移植性差，数据库负荷大等等。。

网上也有很多人不赞成用存储过程来实现，可是我就不明白了，既然SP有这样哪样的“问题”，那为什么数据库要提供存储过程这样强大的功能呢？今天在一个帖子里看到了一个高手的回答：“OLTP的业务逻辑应该放在OO程序中，OLAP的业务逻辑可以考虑用数据库专有的功能（例如存储过程）来实现。”

下面是OLTP和OLAP的介绍。

*************************

联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的，他同时提出了关于OLAP的12条准则。OLAP的提出引起了很大的反响，

OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。

当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。下表列出了OLTP与OLAP之间的比较。

	OLTP	OLAP
用户	操作人员,低层管理人员	决策人员,高级管理人员
功能	日常操作处理	分析决策
DB 设计	面向应用	面向主题
数据	当前的, 最新的细节的, 二维的分立的	历史的, 聚集的, 多维的集成的, 统一的
存取	读/写数十条记录	读上百万条记录
工作单位	简单的事务	复杂的查询
用户数	上千个	上百个
DB 大小	100MB-GB	100GB-TB

*****************************

看了之后和我有一样疑惑的朋友应该会有所收获吧，不过说真的用惯了SP会上瘾的。。。哈哈。

                                                                                                                                                      mx1029 / 2007.08.02