|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
时间:2008-05-09
事实上,在OO流行或者ORM流行之前,SP是最可移植,可扩展的方法。我在OO的早期,一般都是把一个业务方法封装到一个存储过程中去的。
现在除了OLAP没啥好说的,OLTP中,如果数据量比较大的情况,除了数据库任务相当繁重的操作,业务逻辑建议用纯OO程序实现(一般业务逻辑只是影响少量记录),结转,报表,统计等等还是建议用存储过程。 |
|
| 返回顶楼 | |
|
时间:2008-05-10
关键要看自己的团队的知识层次如何, 还要看看将来的应用环境是什么?
如果你的团队都倾向数据库端,数据库技能强, 那么如果你一个人去偏向JAVA, 这个恐怕团队都没法领导。 反之亦然 。 如果你面对的是遗留系统或者海量的数据, 那么把业务逻辑都放的JAVA里肯定不妥 因为我们知道内因才是决定事物的根本因素,有些问题还真得从数据库内部来解决。 当然如果用JAVA等相关的技术是比方便的,那就要大胆的用, 一句话,要计算好投入产出比! |
|
| 返回顶楼 | |
|
时间:2008-05-12
potian 写道 事实上,在OO流行或者ORM流行之前,SP是最可移植,可扩展的方法。我在OO的早期,一般都是把一个业务方法封装到一个存储过程中去的。
现在除了OLAP没啥好说的,OLTP中,如果数据量比较大的情况,除了数据库任务相当繁重的操作,业务逻辑建议用纯OO程序实现(一般业务逻辑只是影响少量记录),结转,报表,统计等等还是建议用存储过程。 嗯,和我们的方式基本一致。 |
|
| 返回顶楼 | |
|
时间:2008-05-13
Joo 写道 速度不是企业应用的唯一且最要紧的诉求
我不知道还有什么? 如果你公司叫google,你会说钱不是问题,为了提高性能,你花很多钱 但是你公司非google,你会说问题是没钱,为了省钱,你接受很低性能 |
|
| 返回顶楼 | |






