一类查询统计问题的纵深思考.docVIP

源数据表——“内部帐户”部分属性的定义： 目的数据——内部帐户余额合计表及其属性的定义 在2个表中有3个属性（机构、币别、科目）是相同的，而这3个属性恰好是中的分组条件 看表1 中的“帐号”属性。由于表2是保存分组条件下所有帐户的余额合计，所以该表中没有“帐号”这个属性是必然的，因此该区别对的解决方案没有任何影响，不必考虑。 剩下的就只有2个关于余额的属性了。它们之间的差别则是显然的：表2中并没有表1中的状态属性“帐户余额方向”和“帐户余额”属性，但新增了“借方余额”、“贷方余额”2个新属性。仔细看看，这2个新属性实际上是由表1 中“帐户余额方向”状态值（借方、贷方）结合了“帐户余额”这个属性产生的。 可以知道解决的关键是：在统计帐户余额时，需要将表1中的“帐户余额方向”的状态值和“帐户余额”属性转化成表2中的“借方余额”属性和“贷方余额”属性。 方案模型A 1 ——GROUP BY 子句 STEP1：SELECT gl_bal_dire_flg, SUM（gl_acct_face_bal） FROM glacaaca GROUP BY gl_bal_dire_flg； -- 列“gl_bal_dire_flg”=0（借方）的SUM值为R1，=1 （贷方）的SUM值为R2； STEP2：INSERT INTO gltottot VALUES（999999999,999,R1，R2）； 方案模型 ——利用数据库的文本文件插入机制： STEP1：将A1 从源数据表glacaaca统计产生的结果写入一个文本文件（假设为glacaaca.txt）。 STEP2：将该glac aaca. t x t 插入到目的数据表glt otto t中。 思路已经出来了，但问题是由文件插入到表中，必须满足一个前提：文件内容的格式与表的数据结构一致。显然，glacaaca.tx t 的内容格式与glt otto t 的数据结构并不一致。因此，需要在STEP1和STEP2之间增加一个步骤：对glacaaca.txt 的内容进行加工，确保其内容的格式与gltot tot 的数据结构保持一致。 方案模型A 2 ——批处理方案 STEP1：UNLOAD TO glacaaca.txt SELECT gl_bal_dire_flg, SUM（gl_acct_face_bal） FROM glacaaca GROUP BY gl_bal_dire_flg； -- 列“gl_bal_dire_flg”=0（借方）的SUM值为R1，=1 （贷方）的SUM值为R2； -- glacaaca.txt文件内容如下： 0|R1 1|R2 STEP2：——编写一个程序对glacaaca.txt进行加工处理： 将2行文本变为一行文本，并存入另一个名为gltottot .txt的文件中；其内容如下（注意格式有所变化）： 999999999|999R1|R2 STEP3：LOAD FROM gltottot.txt INSERT INTO gltottot； 可也正是这个步骤，产生了一个新问题：这个步骤是必须的吗？如果有很多类似的查询，是不是每个都要额外写上这么一个文件处理程序？毕竟仅为了解决一个查询统计而单独编写一个对文本文件进行加工处理的辅助程序，无论从运行效率还是从开发效率的角度分析， 都将会使问题复杂化。 下面摘录的是一段比较真实的代码，是用Informix 的SPL编写： 表5 ：方案模型A 3 ——存储过程 ?? STEP1：FOREACH cursor1 FOR SELECT gl_opun_cod, gl_acct_typ, gl_lg_no, gl_bal_dire_flg, gl_acct_face_bal INTO cod, typ, no, flg, bal FROM glacaaca ORDER BY gl_opun_cod, gl_acct_typ, gl_lg_no, gl_bal_dire_flg； -- 排序的意义等同于分组，并决定是INSERT还是UPDATE； -- 建议在排序之前针对要排序的列建立索引，有助于提高 效率； STEP2：IF flg=0 THEN -- 根据余额方向决定余额进行累计； dr_bal = bal; cr_bal = 0; -- 将帐户余额累加到借方余额 ELSE dr_bal = 0; cr_bal = bal; -- 将帐户余额累加到贷方余额 END IF STEP3：IF cod=p_cod AND typ=p_typ AND no=p_no THEN -- 与上条记录相同，UPDATE UPDATE gltottot SET (gl_dr_bal, gl_cr_bal)