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

cow977

这是一个没有最好,只有更好的问题, 哪个适于你的就是最好的.

WESTLIFE_XU

从来没有绝对的对和错。
不用存储也不代表dba不精通存储过程。
我不理解楼主数的业务逻辑集中的意思是什么。
新业务频繁上线，老业务经常调整，sql众多的话，维护管理存储过程的成本应该也不小吧。
我见过单单update 一张表可能存在几百个sql的变种，程序上应该是很容易拼的，注：不是所谓的动态sql。
很多时候数据库可能只定位存储数据，其他的事情尽量不通过数据库来处理，更别说对业务逻辑的脚本维护了，应用程序能简单实现是否一定需要放到数据库来管理，带来的真正的好处到底有多大？

newkid

原帖由 yzsind 于 2011-2-15 09:24 发表

从DBA的角度看确实很麻烦，但是在架构师眼里不是问题，因为很多系统的底层框架就支持了不同数据库的分页，程序员只要给出SQL,底层框架自动会转换成不同数据库的分页语法。实际上很多实现跨平台数据库的解决方案都需要有底层框架的支持，程序员只要按规范做就OK了。
很多系统要求跨数据库平台都是出于客户需求。如，你一个软件开发出来，软件卖5万元一套，数据库支持的SQLSERVER（2万元），当有一天你的新客户说我不想采购SQLSERVER，因为我已经有了ORACLE数据库，而且我有ORACLE专业DBA维护系统，如果你的软件不支持ORACLE那我就选择其它软件。OK，软件开发商就会研究如何让他的软件适应于ORACLE。当客户越来越多了，为了打开市场，他可能又开始支持DB2,MYSQL之类的数据库，在这样的发展过程中架构师首先想到的是减少非标准SQL，并且通过底层架构去屏蔽不同数据库的语法，最终实现了跨数据库支持。
存储过程由于语法差异太大，而且是放在数据库系统里，所以从架构上很难支持跨平台。

你的博客文章中也有分页的介绍，光是ORACLE就有好几种技巧，都是SQL层面的。底层框架能生成这样的SQL?
你说的可以随便换数据库的软件，从ACCESS到ORACLE都支持，一般都是属于“桌面级”的。“企业级”的应用要么和某种数据库绑定，要么花了大成本对不同数据库进行优化编码，要么就性能很差。一般情况下，高档应用说服客户采用ORACLE并不难，ORACLE在业界的地位摆在那里；你的数据库是应用的核心部件，并不是一个可以随便替换的存储设备，这一点一般客户也能够理解。

newkid

原帖由 dayspring_chen 于 2011-2-15 13:51 发表
应用是复杂的。
我项目初始，大致面临这样的应用：
企业所得税申报表查询：业务分为核定征收（B类）、查账征收（A类），时间线上分为季度预缴、年终汇算清缴，A类还细分为金融、小会计、其他等；每类申报表约有十几张，每张申报表有数百到上千项不等；申报表两三年会换一次版,有些表表内有主从。
客户的要求很简单：所有的数据项都能做条件、所有的数据项都能做结果，能查清单，能做汇总，能导出xls，能打开带格式的套表。总之一句话“想查什么就查什么，想怎么查就怎么查”。
不仅如此，还要关联上登记信息、税费信息、申报信息、入库信息、稽查信息。
这个绝对是50个静态SQL搞不定的啦。组合起来估计10万百万都未必挡得住。
经过验证，9i10g后的动态sql还是可以的。尤其是11g，有了更大的增强。（execute immediate 不受varchar2的限制，跟dbms_sql一样了）
当然，大量用表函数的是另一个项目。不过总体上在存储过程里，不用动态sql简直是没法过活。呵呵，我在当年oracle 7的时候就用dbms_sql做动态sql的项目了。当时做了一个通用接口程序用于交易系统，也没碰到效率问题。
至于维护问题，有了稳定的熟悉数据库编程的团队，比一群只会struts的java散兵游勇让人放心多了。会java的人很多，真正明白机理，能够趋利避害的人就太少了。
看着一坨一坨的java里的业务逻辑，才让人抓狂呢。
----------------------------------------------------------------------------------------------------------------------------
至于业务逻辑就应是代码的说法，我觉得也有些绝对。各种框架里的配置文件，不就是各个框架抽离出的业务逻辑吗。
如果抽象的好的话，完全可以把业务逻辑抽离成元数据，再用代码解析请求，与元数据逻辑进行结合，完成业务处理。可维护性不见得比某些繁琐的框架更差吧。至于叫业务规则引擎，也未尝不可，只是看规则的范畴和抽象的粒度而已。我是考虑一直抽象到可形成持久化语句的。
---------------------------------------------------------------------------------------------------------------------------

你相当于做了一个报表工具，这里使用动态SQL是不可避免的。
至于这个业务规则引擎，现在做到哪一步了？你不妨拿些简化的例子出来讨论一下。必须承认做这类东西对一个爱动脑筋的程序员是很有诱惑力的，但是结局一般都不乐观：
1. 随着需求的深入，抽离的业务逻辑越来越灵活，到最后你相当于发明了一种语言，这种语言世界上只有几个人能懂。配置元数据比写程序还复杂，比程序还更看不懂。
2. 一不小心没配置好，这个规则引擎就会产生怪异的行为。
3. 配置的组合是无限的，但是你只能对其中的某些做测试，其他的只好听天由命。
4. 引擎部分的代码极其抽象，作者要能知道它会生成什么代码，那些生成的代码又是如何运作的。到最后只有作者本人能够维护这个引擎，其他人不敢动。
5. 有很多临时产生的需求，来不及修改殷勤，就采用元数据+客户化代码的方法。到最后, 客户化代码越来越多，因为大家发现这是解决问题的最佳方法！

dingjun123

基本同意newkid的观点
真正要做到数据库的可移植性，那是很难的，除非是个小项目或小软件，大型系统想更换数据库，那付出的精力和money不是一点点。
电信BOSS系统采用oracle,迁移到其他数据库，那最少百人团队，耗时也会很长，资金应该有亿级，还有后续维护乱七八糟的问题和资金投入，难度可想而知。
用一个东西，就是要将这个东西最大化利用，不然为什么选择oracle呢？这不是靠一个hibernate什么的框架就可以实现的可移植，还有比如数据库的封锁机制，事务处理机制什么的，oracle的实现很不同的，通用程序的编写难度可想而知。

newkid

原帖由 WESTLIFE_XU 于 2011-2-15 17:30 发表
从来没有绝对的对和错。
不用存储也不代表dba不精通存储过程。
我不理解楼主数的业务逻辑集中的意思是什么。
新业务频繁上线，老业务经常调整，sql众多的话，维护管理存储过程的成本应该也不小吧。
我见过单单update 一张表可能存在几百个sql的变种，程序上应该是很容易拼的，注：不是所谓的动态sql。
很多时候数据库可能只定位存储数据，其他的事情尽量不通过数据库来处理，更别说对业务逻辑的脚本维护了，应用程序能简单实现是否一定需要放到数据库来管理，带来的真正的好处到底有多大？

业务逻辑集中的意思: 把业务逻辑集中到一个层，而不是到处分散，这样便于维护。对我来说，这个集中的地方应该在数据库，就是存储过程中。

“新业务频繁上线，老业务经常调整，sql众多的话，维护管理存储过程的成本应该也不小吧。”
不管你把“业务”写在那里，都有维护管理成本，何以见得存储过程的成本就更高？

"我见过单单update 一张表可能存在几百个sql的变种，程序上应该是很容易拼的，注：不是所谓的动态sql。"
你既然提到了“拼”，那就是动态SQL, 存储过程一样能拼。

"应用程序能简单实现是否一定需要放到数据库来管理"
应用程序能简单实现的，存储过程一样能够简单实现。

dingjun123

那些什么跨平台的数据库解决方案，基本都是些简单的通用解决方案，只能实现少部分的跨平台，比如sql,底层转为标准sql,或兼容几种数据库的分页写法，但是更多的跨数据库平台，比如一些数据库特有的锁和并发处理，存储过程什么的，想兼容就难了。有一些数据库比如db2说兼容pl/sql,估计也没有达到完全兼容，而且这是要额外付费的。

真正兼容多种数据库平台的软件或项目，必然会遇到很多的问题，有的问题是很难解决的，到时候就忽悠来忽悠去或维护来维护去...

〇〇

兔子回来了?这2天正做测试4种数据库,跨平台太麻烦

〇〇

原帖由 newkid 于 2011-2-15 22:59 发表


你相当于做了一个报表工具，这里使用动态SQL是不可避免的。
至于这个业务规则引擎，现在做到哪一步了？你不妨拿些简化的例子出来讨论一下。必须承认做这类东西对一个爱动脑筋的程序员是很有诱惑力的，但是结局一般都不乐观：
1. 随着需求的深入，抽离的业务逻辑越来越灵活，到最后你相当于发明了一种语言，这种语言世界上只有几个人能懂。配置元数据比写程序还复杂，比程序还更看不懂。
2. 一不小心没配置好，这个规则引擎就会产生怪异的行为。
3. 配置的组合是无限的，但是你只能对其中的某些做测试，其他的只好听天由命。
4. 引擎部分的代码极其抽象，作者要能知道它会生成什么代码，那些生成的代码又是如何运作的。到最后只有作者本人能够维护这个引擎，其他人不敢动。
5. 有很多临时产生的需求，来不及修改殷勤，就采用元数据+客户化代码的方法。到最后, 客户化代码越来越多，因为大家发现这是解决问题的最佳方法！

这正是我参加的数个项目的真实写照,那些语言被用户学了又扔了
因此我现在也不学了,只学sql..
application with software come and go, data will live longer

dayspring_chen

-----------------------------------------------------------------------------
你相当于做了一个报表工具，这里使用动态SQL是不可避免的。
至于这个业务规则引擎，现在做到哪一步了？你不妨拿些简化的例子出来讨论一下。必须承认做这类东西对一个爱动脑筋的程序员是很有诱惑力的，但是结局一般都不乐观：
1. 随着需求的深入，抽离的业务逻辑越来越灵活，到最后你相当于发明了一种语言，这种语言世界上只有几个人能懂。配置元数据比写程序还复杂，比程序还更看不懂。
2. 一不小心没配置好，这个规则引擎就会产生怪异的行为。
3. 配置的组合是无限的，但是你只能对其中的某些做测试，其他的只好听天由命。
4. 引擎部分的代码极其抽象，作者要能知道它会生成什么代码，那些生成的代码又是如何运作的。到最后只有作者本人能够维护这个引擎，其他人不敢动。
5. 有很多临时产生的需求，来不及修改殷勤，就采用元数据+客户化代码的方法。到最后, 客户化代码越来越多，因为大家发现这是解决问题的最佳方法！
-----------------------------------------------------------------------------------
嗯，newkid说的很对，这是开发这类基于元数据变成必须控制的地方，即规则的复杂程度及处理规则引擎的复杂程度。
不要忘记我也是一个玩了oracle十几年的人了。从95年开始玩起的。
1.最早做的是一个接口程序
  就是约定传输的业务表单格式串，依据规则进行解析，分解成主从的结构的insert语句，支持字段级、记录级、表单级规则校验，支持主键自动生成。最早做的是插入操作，后来扩展到更新和删除的业务支持。
  这个项目的场景上有一个核心系统支持数据采集，但后来需要支持多种外部方式的数据插入（网上申报、ocr之类的）。当时设计的元数据结构还是覆盖全面的，基本上交易系统的规则都能够覆盖到。维护的话也还好，对SQL、PL/SQL熟悉的人培训个一周就可以维护了。
  当时还是oracle7，动态sql用dbms_sql搞定，状态信息用raise_application_error传递，呵呵。
2.后来做了一个基于j2ee的三层架构的通用查询
  做过通用查询的都知道，这玩意可很难。最典型的问题是：因为需要处理一个条件需关联一个表，因为关联这个表必须用外连接；主关联从表导致主表的记录数被成倍放大（最糟的是笛卡尔集），汇总统计的主表数据出错；条件数过多的时候拼接的sql已经无法理解，条件和条件间互相影响（机构、时间？），结果和结果间互相影响，条件和结果间互相影响；条件集和结果列无非同一数据集时很难处理等。
  这个我确实等于自己创造了一套理论，将这些都解决了。而且还实现了：业务复合时间支持（如支持年、半年、季度、月份的复合处理），条件集的SQL优化（包括条件位置的多点替换），结果集通过外连接支持样式套表打开。
  最大的查询包括4000多的条件和结果组合，都工作和管理的很好。我已经可以放心让手下人进行维护。也曾和oracle的技术人员进行交流，他们对这种处理也很认可，只是感叹这个唯一的不足是只支持oracle。
3.后来做了一个基于j2ee的三层架构的通用报表
  报表显示等是基于润乾的。在润乾之外包装了一层管理层，将报表分为按版本（有效起始终止日期的）划分的子报表，每个子报表有自己的时间、机构等级、前后台、生表前条件校验、生表后特殊处理、报表确认审核、报表回退、报表模板设置。后台调度生表使用的是job，表结果存储最初使用的是clob的xml，后来一时糊涂改成了nest table，最近在考虑要不要改成json。
  总体上这个东西做的还可以，满足客户要求和扩展性都还好，汇总表、表间取数、平衡审核、转换总局之类的都是用存储过程实现维护在代码表中，无论开发效率还是运行运行效率都很高。
4.那个业务规则引擎是我再总结当前交易系统弊端加上对以前用存储过程开发进行反思后考虑的。
  首先有以前做通用接口的经验，有些思路可以借鉴。而且现在技术手段比以前丰富多了。
  当然需要处理以前没有的一些东西，例如webservice、restful等。碰到困难是一定的，但工具就是在应用中磨出来的。至于抽象的粒度及设置的复杂性、覆盖广泛性，必须是设计的人去权衡利弊，进行取舍的。
  当前系统主要苦于：开发人员大部分是java背景的，结果是后台数据结构一团糟，新来业务需求，项目经理往往是新建一套表，导致后台数据不优化，数据利用时必须再另写转换规则进行加工；
  企业级系统的特点是表单多，表单规则复杂，表单随着客户的业务要求，在极短的开发时间内完成修改，且变化的表单前后业务还有很多制约要求。（呵呵，有点像缓慢变化维，可以叫缓慢变化表单）
  开发人员耗费了很大精神在中间层上，用javabean模拟表进行业务逻辑操作。结果是中间的业务逻辑越写越复杂，前台UI客户不友好，后台数据结构BI开发不友好。感觉项目的开发工作没有用在合适的地方。
  至于那个引擎，打算今年开始动手实践，先找个适中的项目做实验。至于你提到的那些副作用，当然很感谢提醒，我也会尽力避免。在功能、灵活性、可维护性间取得平衡。绝不会一意孤行，自取灭亡的。
  做元数据设计，1000个架构师可能有1000种设计法，戏法人人会变，各有巧妙不同的。