re: 关于数据库存储过程的一些讨论

newkid · 发表于 2011-2-12 00:14

原帖由 dayspring_chen 于 2011-2-11 09:48 发表
1.把存储过程做成调用接口包。
2.为了更方便不同客户端调用，可以用表函数作为访问方式（以自治事务进行DML，用表函数返回状态信息）
3.存储过程里面用动态sql（execute immediate,dbms_sql）,通过访问元数据表读取业务规则，实现访问控制。即业务逻辑并不在存储过程中，而在元数据表中。
4.通过维护元数据表来进行业务扩展、业务调整、业务作废工作。元数据表加上机构级别、业务起始终止时间、自定义限制等，实现生命周期及细粒度控制。
5.在此基础上，将开发团队分为3个组：数据处理组、工具组、业务定制组，以简驭繁，对项目需求进行分解，实现极限编程。
已经在3个以上项目中按此方式实施。如有兴趣请加我msn:dayspring_chen@yahoo.com.cn。

我很不赞同你的一些做法。
2.为了更方便不同客户端调用，可以用表函数作为访问方式（以自治事务进行DML，用表函数返回状态信息）
为什么用表函数就更方便？
你全都是用表函数返回嵌套表，然后用SELECT...FROM TABLE(...)? 这样有什么好处？
如果要返回结果集，可以打开一个REF CURSOR并返回。
自治事务要特别小心。基本上，除了写日志，其他的应用都是错的。你这样做，将不得不把COMMIT放到你的函数里。这是不提倡的，COMMIT最好交给客户端去处理。另外你的函数将很难模块化，因为每个都是不同的事务！比如函数A调用函数B, A和B应该在同一个事务里，你如果在A,B里用了自治事务，全乱套了。
3.存储过程里面用动态sql.....
动态SQL是应该尽力避免的。它的应用范围及其有限，一般是为了组合灵活的查询条件。如果你把事务处理也用动态SQL实现，一定有问题。
动态SQL程序很难读，很难维护，无法在编译的时候发现语法问题；因为多隔了一层，效率也要打个折扣。
你可以把业务逻辑中一些灵活的部分抽出来进行参数化，也就是通过配置的方式来进行控制，但是“执行动作”应该都是静态代码，它只是根据不同的配置走不同的分支。
如果你的需求决定了有很多雷同的代码，那么你可以利用你的元数据来生成静态代码，这样节省了人工，但是最终编译、执行的代码还是静态的。
4.通过维护元数据表来进行....
如果元数据表是我上述提到的配置表，这样的做法是可取的。

newkid · 发表于 2011-2-12 00:15

本帖的反方不怎么给力啊。淘宝的大师们呢？还没上班？

guostong · 发表于 2011-2-12 02:19

原帖由 solomon_007 于 2011-2-11 10:56 发表
TOM 的一本我几年前买的一本书（好象是ORACLE设计优化什么的，具体不记得了）中也提过，开发的原则是：
能一句SQL搞定的就SQL搞定，
SQL搞不定的就PLSQ搞定，
PLSQL搞不定的就 JAVA 外部过程
JAVA 外部过程搞不定的就 C 外部过程
C 外部过程搞不定的就放弃。。。

书名：<Expert Oracle>
原文：
I have a pretty simple mantra when it comes to developing database software:
❑ You should do it in a single SQL statement if at all possible.
❑ If you cannot do it in a single SQL Statement, then do it in PL/SQL.
❑ If you cannot do it in PL/SQL, try a Java Stored Procedure.
❑ If you cannot do it in Java, do it in a C external procedure.
❑ If you cannot do it in a C external routine, you might want to seriously think about why it is
you need to do it...

newkid · 发表于 2011-2-12 02:27

原帖由 guostong 于 2011-2-12 02:19 发表

书名：
原文：
I have a pretty simple mantra when it comes to developing database software:
❑ You should do it in a single SQL statement if at all possible.
❑ If you cannot do it in a single SQL Statement, then do it in PL/SQL.
❑ If you cannot do it in PL/SQL, try a Java Stored Procedure.
❑ If you cannot do it in Java, do it in a C external procedure.
❑ If you cannot do it in a C external routine, you might want to seriously think about why it is
you need to do it...

兔兔有阵子把这作为签名。

guostong · 发表于 2011-2-12 02:59

原帖由 newkid 于 2011-2-12 02:27 发表

兔兔有阵子把这作为签名。

那会儿我还不知道这是 Tom 说的，可崇拜兔兔了.

solomon_007 · 发表于 2011-2-12 08:52

原帖由 guostong 于 2011-2-12 02:19 发表

书名：
原文：
I have a pretty simple mantra when it comes to developing database software:
❑ You should do it in a single SQL statement if at all possible.
❑ If you cannot do it in a single SQL Statement, then do it in PL/SQL.
❑ If you cannot do it in PL/SQL, try a Java Stored Procedure.
❑ If you cannot do it in Java, do it in a C external procedure.
❑ If you cannot do it in a C external routine, you might want to seriously think about why it is
you need to do it...

哈哈，到底是搞技术的，就喜欢刨根究底。。。

楼上的几位都很精力充沛啊，半夜2点还挂在这个上面。。。

space6212 · 发表于 2011-2-12 09:07

我也有很多条理由不用存储过程，其中最重要的一条就是：当你的系统非常繁忙，还是建议把数据库用得越简单越好

ban_ping · 发表于 2011-2-12 09:36

newkid的观点和Tom的一致，我觉得面向传统企业的应用和面向互联网的应用是有很多差别的，对传统企业应用比如ERP系统来说，newkid的说法可能是合适的。很多互联网公司只是把数据库作为在硬盘上持久存储数据的一个工具而已，缓存才是他们核心的东西，而大多也没有十分复杂的业务逻辑，即使有复杂的业务逻辑也是通过异步操作等手段处理，这样能更灵活的处理高并发访问的情况，如果业务逻辑都封在数据库里，实际对数据库运行环境的要求是很高的，扩展方面可能也有问题。