看我做的数据库包装器

yulihua49

原帖由 〇〇 于 2009-7-10 14:33 发表
我更希望c能产生从基层表产生汇总表的1个或多个sql语句（优化后的），然后sql丢给oracle执行，
比如：
create table lt_679
as
select
substr(a.m4,1,2)dzm ,substr(a.m22,1,2)hy ,
sum (case when substr(b.m22,1,2)='63' then 1 end) cnt_63,
sum (case when substr(b.m22,1,2)='63' then b.m40 end) c2,
sum (case when substr(b.m22,1,2)='63' then c.m11 end) c3,
sum (case when substr(b.m22,1,2)='63' then c.m13 end) c4,
sum (case when substr(b.m22,1,2)='63' then c.m17 end) c5,
sum (case when substr(b.m22,1,2)='63' then c.m18 end) c6,
sum (case when substr(b.m22,1,2)='63' then c.m15 end) c7,
sum (case when substr(b.m22,1,2)='63' then c.m4 end)  c8,
sum (case when substr(b.m22,1,2)='65' then 1 end) cnt_65,
sum (case when substr(b.m22,1,2)='65' then b.m40 end) c10,
sum (case when substr(b.m22,1,2)='66' then 1 end) cnt_66,
sum (case when substr(b.m22,1,2)='66' then b.m40 end) c18,
sum (case when substr(b.m22,1,2)='67' then 1 end) cnt_67,
sum (case when substr(b.m22,1,2)='67' then b.m40 end) c29
from
pjpdata.v_8600000002008032207000015 a,
pjpdata.v_8600000002008032207000016 b,
pjpdata.v_8600000002008032207000017 c
where b.m43=a.m1 and substr(b.m22,1,2)in('63','65','66','67') and b.m1=c.m1(+)
group by substr(a.m4,1,2) ,substr(a.m22,1,2);

create or replace function dl2ml(hy in varchar)
return varchar
as
x varchar(2);
begin
select
case
when hy >='01' and hy='06' and hy='13' and hy='44' and hy='47' and hy='51' and hy='60' and hy='66' and hy='68' and hy='72' and hy='73' and hy='75' and hy='79' and hy='82' and hy='84' and hy='85' and hy='88' and hy='93' and hy

要是我，就设计一个语法，然后动态生成模板，剩下的事交给DAU去做，毕竟，过去写了那么多代码，资源要利用一下。
对于你，先设计一个模式化的 词法－SQL语句 接口转换器，然后 设计一个自由语法－模式化词法的编译/解释器。
目的是让不懂程序的业务人员能够按照他们的习惯和语言自由定义处理逻辑和展示结果。OLAP对处理时间要求不太苛刻，这个实现完全可能。当然你的模式化词法要偏重于OLAP。
所以，到现在我们知道了，DAU，就是一个C语言环境下的 SQL模式化词法处理器的样本。使用DAU并不重要，重要的是，我们知道了，有一种办法，能够把一些单词组装成SQL语句，而且效率不低（我在做OLTP，所以必须立即执行，如果OLAP，可以交给其它对象执行）。大家可以用自己合适的语言写贴近用户的功能。
我是抛砖引玉，欢迎大家拍砖，更希望引玉，如交流一下如何构建词法，如何处理单词，如何形成语法和语言？

讨论了这么久，终于OO在416楼道出问题的终极目的。

[ 本帖最后由 yulihua49 于 2009-7-12 10:21 编辑 ]

〇〇

特殊情况下，可用外部过程得到更快的速度
http://www.itpub.net/viewthread.php?tid=1117461&highlight=

yulihua49

原帖由 〇〇 于 2009-7-13 08:52 发表
特殊情况下，可用外部过程得到更快的速度
http://www.itpub.net/viewthread.php?tid=1117461&highlight=

纯计算，程序语言可能更有效些。
我也是基于这个考虑，如果多数事务含有大量计算，偏向以程序语言为主体。要在你的环境下考量，达到总体性能最高。
今天有一个收获，PRO*C可以 select into 到结构。

newkid

要是我，就设计一个语法，然后动态生成模板，剩下的事交给DAU去做，毕竟，过去写了那么多代码，资源要利用一下。

#416要的是能够生成某种套路的SQL, 相信很多BI工具都能做到。"剩下的"就是执行并展示结果，那更是BI工具的拿手好戏，何苦用什么DAU?

对于你，先设计一个模式化的 词法－SQL语句 接口转换器，然后 设计一个自由语法－模式化词法的编译/解释器。

有工夫去设计学习#417那种词法，我还不如掌握sql呢。

纯计算，程序语言可能更有效些。
我也是基于这个考虑，如果多数事务含有大量计算，偏向以程序语言为主体。要在你的环境下考量，达到总体性能最高。

请举个例子，什么样的事务含有大量计算，要转移到数据库之外完成？现实中大多是四则运算，sql轻松搞定。

〇〇

用我自己的经历代lz说明

原帖由 newkid 于 2009-7-14 04:15 发表

#416要的是能够生成某种套路的SQL, 相信很多BI工具都能做到。"剩下的"就是执行并展示结果，那更是BI工具的拿手好戏，何苦用什么DAU?

我们做一个通用的支持用户自定义的专业程序交付给用户，bi工具不能任意分发

有工夫去设计学习#417那种词法，我还不如掌握sql呢。

我们过去开发一个专业程序就创造一种词法,用户有的喜欢学,有的不喜欢学,最近开发的全是拖曳操作产生谁也看不懂的内部码,错了连错在哪也不知道,但是用户还是觉得sql难学

请举个例子，什么样的事务含有大量计算，要转移到数据库之外完成？现实中大多是四则运算，sql轻松搞定。

就是10年以前我们同事测试的proc比sql同时汇总很多表要快，当时写sql的也是一个oracle高手

〇〇

原帖由 〇〇 于 2009-7-14 12:26 发表

就是10年以前我们同事测试的proc比sql同时汇总很多表要快，当时写sql的也是一个oracle高手

刚才和这位同事通了电话，他说当时汇30张汇总表以内的，sql快，超过30张汇总表，proc快，我只测试了1张表。。。

yulihua49_cu

原帖由 newkid 于 2009-7-14 04:15 发表

#416要的是能够生成某种套路的SQL, 相信很多BI工具都能做到。"剩下的"就是执行并展示结果，那更是BI工具的拿手好戏，何苦用什么DAU?


有工夫去设计学习#417那种词法，我还不如掌握sql呢。


请举个例子，什么样的事务含有大量计算，要转移到数据库之外完成？现实中大多是四则运算，sql轻松搞定。

唉！你老是说你，世界有几个你？
要是你，当年你会写几百个存储过程给统计处，我写了7个程序，有几百个脚本是他们自己写的，统计口径和报表经常变化，都是他们自己维护。要是我维护还不累死我？
有个叫BO的东西。我先前的统计系统（就是这种词法脚本，当然，那时没有DAU），计算全分局的日统计，10秒，后来用BO，18分钟。这就是差别。
我和基层的操作人员打交道太多了，别说SQL，英文根本不懂，键盘上字母找不到，操作完全靠小键盘。看我那个天书，基本只用数字。他们根本不喜欢鼠标，
最好就是小键盘盲打。眼睛看报表，根本不看屏幕，动作快极了。

不管谁，统计分析系统是变化最快的了，你不仅需要考虑开发速度和运行速度，还要考虑日后的维护变更。
如果你是软件开发商，存储过程源码你大概不想提供客户吧?(j就是提供，多半人家也看不懂，更不敢改)
如果客户不能自行维护统计系统，人家根本就不会买你的产品。

当年没有DAU，也实现了统计脚本。如果有DAU，脚本软件更容易写，效率也更高。
其实DAU的思路就来自当年的统计脚本。

回答你：词法分析和语法解释，C语言绝对比SQL效率高。我们这种边解释语句，边访问数据库边构建表格的软件最适合C语言，无论PRO*C，OCI或DAU。
中国人用的软件需要中国特色，有时就需要自己的工具，中国软件业才有生存空间。
天天BO，BI什么的，能满足中国的需求吗？

[ 本帖最后由 yulihua49_cu 于 2009-7-14 18:08 编辑 ]

newkid

我们做一个通用的支持用户自定义的专业程序交付给用户，bi工具不能任意分发

那么你就是因为licence成本的问题自己开发了bi tool, 即使要这么做，现在有一些开源的项目可以借鉴，仍然和DAU没什么关系。
楼主的DAU仅仅能够产生单表的select,(非主键的where还得自己写), 复杂的SELECT必须用手工模板（手写SQL）, 或者其他的SQL生成工具，在报表领域基本无用。

我们过去开发一个专业程序就创造一种词法,用户有的喜欢学,有的不喜欢学,最近开发的全是拖曳操作产生谁也看不懂的内部码,错了连错在哪也不知道,但是用户还是觉得sql难学

这样的词法是针对某种特殊用途的，灵活性和SQL不可比。
如果一定要做，只需要把表名、列名、SQL关键词作一个简单的中英文映射，也比自己发明的更强。

就是10年以前我们同事测试的proc比sql同时汇总很多表要快，当时写sql的也是一个oracle高手
刚才和这位同事通了电话，他说当时汇30张汇总表以内的，sql快，超过30张汇总表，proc快，我只测试了1张表。。。

那是10年前，现在呢？汇总什么意思？如果是SUM GROUP BY, 我不相信在数据库外面做加法更快。
30张表什么意思？是JOIN 30张表，还是30个并行SQL?

newkid

不管谁，统计分析系统是变化最快的了，你不仅需要考虑开发速度和运行速度，还要考虑日后的维护变更。
如果你是软件开发商，存储过程源码你大概不想提供客户吧?(j就是提供，多半人家也看不懂，更不敢改)
如果客户不能自行维护统计系统，人家根本就不会买你的产品。

某些复杂报表用存储过程（用户无法自己维护）；普通的用报表生成工具。

当年没有DAU，也实现了统计脚本。如果有DAU，脚本软件更容易写，效率也更高。
其实DAU的思路就来自当年的统计脚本。

上面说过了，一个汉化的简板sql也比你#417的天书要好。

回答你：词法分析和语法解释，C语言绝对比SQL效率高。我们这种边解释语句，边访问数据库边构建表格的软件最适合C语言，无论PRO*C，OCI或DAU。

你还不如说3D动画用C比SQL效率高呢！你说的那个是解释器、编译器的范畴，当然不能用sql来做。我说的是事务处理，就是你这个售票系统里大部分的东西。

http://en.wikipedia.org/wiki/OLTP

yulihua49_cu

原帖由 newkid 于 2009-7-14 23:08 发表

某些复杂报表用存储过程（用户无法自己维护）；普通的用报表生成工具。

当然，全世界都这么做。但在中国，能让用户自行维护的系统不多，都需要专业人员协助。



上面说过了，一个汉化的简板sql也比你#417的天书要好。
我们看是天书，业务人员自己看得明白。



你还不如说3D动画用C比SQL效率高呢！你说的那个是解释器、编译器的范畴，当然不能用sql来做。我说的是事务处理，就是你这个售票系统里大部分的东西。
是。

http://en.wikipedia.org/wiki/OLTP

介绍一下天书的思路，它是跟业务人员商定的描述方法。我没有要大家按我的思路做的意思，想说一下如何和业务人员沟通的问题，你们的用户当然你们去沟通，写你们的脚本。
首先，不要跟他们讲什么标识符、表达式、语句、函数、过程等等，人家晕。

.,01,A1,102,1..28;
当日的 01单位的 A1表的 当日数的 1至28项输出。（分号是打印命令）

变换成SQL就是：
select tjdate,unit,tabname,flg,dat1,,,,dat28 from tjrb where tjrq=to_date(:1,'YYYY-MM-DD') and unit=:2 and tabname=:3 and flg=:4

上面的脚本，统计人员很理解，这简单的SQL语句他们就整不了，复杂的更别提。他们不可能去玩存储过程，但是在编辑框里写脚本是没问题的。

还有参数问题，我们习惯@item这样的标识，但他们不，认为#1，作为1号参数。。。。。#已经做注释用了，改@吧，就这么定了。如下：

for <!  @1,@2   #用下一行至！的内容替换@1，@2参数。
A1,28
A2,24
!
.,01,@1,102,1..@2;
endfor
#产生：
.,01,A1,102,1..28;
.,01,A2,102,1..24;


他们职业习惯，用数字标识数据。

还是那句话，你们的脚本采用什么语法，跟你们的业务人员谈，能否生成高级的SQL语句是你们的本事，是否可靠，易调试也是你们的本事。
在这里，性能不是最重要的，10秒的活存储过程也许5秒就干完了，这是无所谓的，但是弄到好几分钟就比较烦人了。

[ 本帖最后由 yulihua49_cu 于 2009-7-15 14:22 编辑 ]