业务逻辑在存储过程实现与在中间层实现的讨论

guo

我还是认为中间层进行复杂的业务处理是没有优势的

另外中间层和oracle间的处理如果不用oci/proc那你用什么?

sqlcode

业务处理在中间件实现的优点：

1. 可以多个Server并行处理,提高处理能力,扩充性非常好;
   存储过程的执行是顺序的,若有多个请求调用,只能排队,存储过程就成了系统的瓶颈.而采用中间件,当系统处理能力达不到时,可以多起Server,甚至动态加入并行主机. 从这一点上说,中间件的性能更高一些.

2. 资源级(Queue,Oracle,Informix...)的全局事务保证交易的完整性, 存储过程是绑定数据库的,无法实现;

3. 可靠消息队列(Queue)实现可靠传输业务,远程存储过程调用是不可靠的;

4. 数据依赖路由;

5. 支持分布式系统, Tuxedo/Domain结构中各个域相互独立,通过信任关系调用对方的Service,可以方便复杂系统的划分,支持跨域事务.
这些优点是SP所不能实现的.其它优点多多,参见 BEA Tuxedo Trainning Material.(这些都是真的哦,我和BEA没有任何关系)

业务处理在中间件实现的缺点：
1. 速度问题: 作为一个适用于OLTP系统的交易中间件,若不采用XA方式,需要用户自己控制事务;若采用XA方式,由于要记录全局事务日志(TLOG),处理非常慢,尤其是处理实时任务时,Server是被动的,发起者调用Server,执行的方式为单条提交,速度更是无法忍受(<100条记录/秒)
    作为Tuxedo一大卖点的可靠队列(Queue)速度更是无法忍受, <50条/秒
   
    BEA建议在实时处理中打包（几十条）处理，速度确实提高很多，但失去了实时的意义，而且要控制打包和拆包，按记录字段路由等Tuxedo优势都丧失了。

2. 增加了开发、调试、测试的复杂度: 开发Server使用C语言(访问数据库嵌入SQL,如:Pro*C),实现业务逻辑;前台使用可视化开发环境,用来输入数据和显示数据. 开发任务比两层结构多了很多,如果再使用存储过程,调试需要前台界面、后台Server、存储过程协调进行，大大增加了调试的复杂度，而且一般的开发队伍中都是做前台界面的专门做界面，开发后台的专门做后台，这样组装调试就更加困难了。

3. 事倍功半的查询处理: 交易处理开发复杂还划算，因为毕竟Tuxedo带给了我们并行、可靠、全局事务等好处，但是使用三层结构做查询处理就太亏了，本来就是简单的给一个条件查出结果显示就OK了，现在要前台输入查询条件，传送给Tuxedo Server,Tuxedo Server根据输入的条件查询数据库，再把数据传送给前台。在Tuxedo中一般使用FML传送数据，若结果有很多，还要控制翻页等功能，复杂得一塌糊涂。若使用两层结构（如PB+Oracle），举手之劳！

其它好多好多问题,如:系统的稳定性,...(算了,与主题无关不说了,免得大家对Tuxedo失去信心,也免得遭BEA扁)
其它中间件也是问题多多.

我建议的策略:
1. 请求非常频繁的业务处理,使用Tuxedo/T;
2. 可靠传输事务(广域网)使用 Tuxedo/Q;
3. 查询处理使用两层结构实现;
4. 系统级的操作, 不需要交互,不存在并发问题的交易, 如定时记帐等, 采用数据库存储过程完成;
5. 跨异构数据库的事务,使用Tuxedo/T

我的原则:
开发工具是为我服务的,我要去其糟粕,取其精华.

blazebird

to sqlcode
   tuxedo号称很稳定，倒底有哪些稳定性问题？不要只说半句话。
不过我用它的一些图形界面的开发工具倒真是有些问题。
还有tuxedo8.0的webgui，第一次登陆时界面花了一个多小时才出来（win2000），不知道那个java在干什么，反正BEA的人说他也没用过。
   
  对于存储过程会成为瓶劲其实问题不大，数据库服务器多加个cpu，加点内存，相当于你加一台运行tuxedo server的机器，还好管理。
   对于大结果集的查询，我认为是设计者的问题，这么大的结果集查出来有什么用？我们做查询从来是限定结果集大小的，通过多次请求来返回后面的数据。

sqlcode

不稳定:
1. 我们的域Server(GWADM)经常DOWN,不报任何错误,BEA正在解决;
2. 多机的跨域事务经常无法提交,不报任何错误;
3. QUE在网络不是特别好的情况下,居然会不先进先出(设置了FIFO).
其它小的都忘了....

存储过程的瓶颈并不是增加cpu和内存能解决的,我们做过这种尝试.串行处理和并行处理的性能是显然的,更致命的是当存储过程被调用得非常频繁时,直接影响数据库其它操作的性能. Tuxedo系统的初衷是把数据库解放出来,专门从事数据相关的操作,如大数据量的查询等.本来运算等业务处理就不是数据库的强项,这一点虽然对于我们这些喜欢数据库的同学有点接受不了,但这个确实是能够提高系统的性能.

采用限定结果集大小的方法,每次取出一部分,SQL执行的时候,每次都要重新解释执行,浪费了许多时间.这个用SQL 的统计工具可以统计出来.不知道你们控制结果集的办法是怎么样实现的(如方便,请告知), 我曾尝试过作视图用rownum实现,但是每次的SQL都肯定要重新解释的,如果有一个查询被分成100个结果集,那么解释的代价也不小啊.

大结果集的问题: 我也觉得查询没有什么意义,总结出综合数据就够了,用一个饼图或直方图表示一些就完了.但是用户有这个需求,不能不作啊. 每天几千万的数据量,如果查询1/10000的话,也要查询到几千条,设计者能怎么样呢? 估计用户用一次之后就再也不会用了(哈哈哈).

blazebird

系统的瓶劲可以通过监控服务器的状态来分析：cpu的利用率、内存交换情况，i/o情况。

一般来说数据库应用系统的性能还与写的程序有关，有些地方可以不加锁的就不要加锁，有的地方可以脏读的就不要加锁读。不同事务中对相同几个表的处理顺序要确保一致,资源竞争导致性能相降。当然重要的是索引策略是否适当。

sqlcode

大部分数据库应用系统的性能问题都是程序的问题,现在做项目硬件一般是没问题的.  SQL语句的写法是另一个非常重要的方面, 同一个操作使用不同写法的SQL , 会有非常大的性能差异, 所以我觉得补充一点的就是要优化数据库应用系统中的SQL语句