|
|
原帖由 fan0124 于 2010-6-29 10:51 发表 ![]()
在Oracle中，存储过程就是PL/SQL的模块
PL/SQL引擎会执行过程化语句，但它把SQL语句传送给SQL引擎处理，然后SQL引擎把处理的结果返回给PL/SQL引擎。
然后SQL引擎把处理的结果返回给PL/SQL引擎。
PL/SQL和SQL引擎间的频繁切换会大大降低效率。
其他语言就没有切换了？PLSQL至少和SQL是在同一台机器上！
原帖由 yueyangflash 于 2010-6-29 13:23 发表 ![]()
将业务放到数据库中去实现 后期维护可能会存在很大的问题！
放到数据库外实现为什么就没问题？
原帖由 yueyangflash 于 2010-6-29 13:23 发表 ![]()
程序员看到存储过程可能并不知道这个存储过程是干什么用的！
那我看到一段JAVA也是一头雾水！
原帖由 dingjun123 于 2010-6-29 14:48 发表 ![]()
全用存储过程可能会带来的问题比大部分用SQL带来的问题多。除非你们的团队存储过程和性能优化特别猛！~ 因为很多人熟悉SQL,但是不熟悉PLSQL，为什么放弃熟悉的而且很好的东西，去用不熟悉的东西呢？当然可能会用到存储过程的，但是绝对不是全部！~
全用存储过程问题多在哪里？
原帖由 wolfop 于 2010-6-29 14:50 发表 ![]()
从应用分层的原则，大量使用存储过程导致业务逻辑分散在DB和应用服务器层，肯定不好开发维护和更新。
从性能来说,SP肯定不是最优的，我知道的案例就有某运营商原来计费批价都用SP，后来很难满足性能的问题。
总体来说，SP可以用，但要很慎重，最好只用来维护，不用于业务逻辑和支撑高并发高性能的东西。
分层也可以分到DB里面。"SP肯定不是最优的", 举个实例看看？有可能是你的SP没写好。
原帖由 fan0124 于 2010-6-29 15:19 发表 ![]()
关于存储过程，首先带来的问题就是业务变动，然后数据库扩展，业务扩展
你怎么弄，扩展十几个数据库时，你去把存储过程迁移十几次去？那不把你搞死
如果业务逻辑变化的时候，怎么弄，改存储过程只有
然后就是在并发比较高的OLTP，性能是很差的
还有对测试人员来说，调试时，你还要他专门跑到数据库里去调试存储过程？如果是SQL，他直接跟踪调试就可以了
“存储过程迁移”？数据才有迁移。如果你是说把程序复制到各个库，不用存储过程难道就不用复制了？应用服务器上也得有程序吧！
“如果业务逻辑变化的时候，怎么弄，改存储过程只有”改就改呗，难道放到外面就不用改。
“然后就是在并发比较高的OLTP，性能是很差的”举个实例。
存储过程的调试并不比其他语言更困难。
原帖由 wisdomone1 于 2010-6-29 17:23 发表 ![]()
各显神通哟，不了解开发，上司就是让用存储过程，我又找不到合适或强有力的说词，唉；不懂开发，没法对比应用与oracle实现业务逻辑的优差性，唉！
列举一个我们的存储过程 ,大体对于每个表皆有select,update,delete,insert对应的存储过程，
--E_TeacherLoginInfo包声明
CREATE OR REPLACE PACKAGE PKG_E_TEACHERLOGININFO
AS
/
你这个只是TABLE层面的API, 就是所谓的TAPI, 好的做法是TOM提倡的XAPI, 即事务级别的API. 事务里面可能有多个SQL, 直接写就是，不必再弄一层表级的API.
原帖由 fan0124 于 2010-6-30 11:49 发表 ![]()
不是说要你一定就像淘宝那样去做
第一，你所在的团队的技术积累是没有达到人家那样的高度很深度的
第二，开发团队能够达到用复杂算法及良好的架构来处理很多复杂运行，性能问题吗（比如说实现复杂的在线分析统计），还没有到那个程度，就只
能让DB去处理
第三，最关键的，你的数据量和并发能达到淘宝那么高吗？没有那么高（楼主的系统实时级别，数据量级别应该不大吧，我可以肯定的说）
能用DB抗的住，那你就用DB抗，但是抗不住了，就要考虑在APP应用上扩展
为什么APP扩展容易，一台机器一部署就好了。但是数据库是要复杂多的
第四，建议还是业务逻辑往应用上放
应用服务器不是最后也要访问DB? 一个事务如果用到10个SQL, 放到应用服务器也是一样，一个都跑不了，最终压力还是会落到DB.
原帖由 horizon 于 2010-6-30 14:23 发表 ![]()
用存储过程移植会出现大问题,可能要重写存储过程也说不定
但应用程序改动会少
如果你说的是换数据库，趁早打消这个念头，不管怎么做都是很困难的。TOM的书专门有一节讲到为什么独立于数据库的想法是不现实的。
PLSQL实际上更为“通用”，在任何操作系统的ORACLE都一样运行；所有的开发语言都可调用存储过程。
原帖由 dahuzizyd 于 2010-7-1 11:36 发表 ![]()
简单的sql操作肯定是不必写到存储过程里的。
假设你有1000张表，仅仅是基本的CRUD操作，都写成存储过程就有4000个，那好，我全都封到包里，那也有1000个包。
再来看单表的操作，C，D操作一般有一个，R，U就不好说了，可能A业务select的时候用10个字段，B业务用5个，C业务用3个，每个都写一个存储过程？同理，A业务更新10个字段，B业务更新5个，C业务更新3个，这样一来，单是针对一个表的CRUD存储过程就有可能超过10个。
好，我打个8折，1000张表，8000个CRUD的存储过程。和你真正处理业务逻辑的存储过程搁在一块儿，光找就得半天。
再者，一个表10个字段，写成存储过程，10个字段都作为参数？这样下来接口是很大的，在前台写sql，反正也要把这些内容都准备好的，通过存储过程，无疑把前后台的耦合度加大了。
sql注入的问题，sql注入是在哪里注入的？前台，那就要在前台控制住，后台数据库管这么宽干嘛？
把所有CRUD都做成存储过程不是办法；存储过程应该以事务为单位。
参数也可以用OBJECT来传递，类似PLSQL的记录类型。
如果你的应用服务器被攻击了，别人可以上传脚本做DML那就很危险。把表的权限都收回，只留下存储过程接口相当安全一些。
原帖由 zhang41082 于 2010-7-1 22:47 发表 ![]()
1、如果你的系统没有十分的繁忙，用存储过程简单，改个BUG、优化个SQL，只要数据库上面把存储过程改了编译一下就好了，不用几十台的APP SERVER去上线
2、如果系统很繁忙（指这个存储过程很忙），那可能你连编译它的机会都没有，一编译整个库就HANG在那里了，那绝对是灾难，这时候上线就要求你把前台业务全部停下来。而用APP端来实现的话，你就可以一台台的上线，业务总体来说不中断
3、数据库的CPU资源、IO资源非常昂贵，而且数据库又容易成为瓶颈还不容易扩展。所以量大的时候，放到APP好扩展
如果你允许新旧版本程序一起跑，才有可能把APP逐个更新。 |
|
楼主: wisdomone1
IP卡
狗仔卡
发表于 2010-7-1 10:11
显身卡
发表于 2010-7-1 10:20
楼主