看我做的数据库包装器

〇〇

cube和那些union的结果是相同的。
希望你能用c写一个不用gruop by语句的cube

newkid

原帖由 yulihua49 于 2010-2-11 14:53 发表

不懂 cube。不过那几个语句DAU是可以做出来的。

GROUP BY CUBE 相当于对所有的列组合做聚合运算，然后把这些结果合并起来。假如CUBE里有N个列，就有2^N种组合。

以三个列为例，

SELECT c1,c2,c3,SUM(amount)
  FROM T
GROUP BY CUBE (c1,c2,c3);

相当于:

SELECT c1,c2,c3,SUM(amount)
  FROM T
GROUP BY c1,c2,c3
UNION ALL
SELECT c1,NULL c2,NULL c3,SUM(amount)
  FROM T
GROUP BY c1
UNION ALL
SELECT NULL c1,c2,NULL c3,SUM(amount)
  FROM T
GROUP BY c2
UNION ALL
SELECT NULL c1,NULL c2,c3,SUM(amount)
  FROM T
GROUP BY c3
UNION ALL
SELECT c1,c2,NULL c3,SUM(amount)
  FROM T
GROUP BY c1,c2
UNION ALL
SELECT c1,NULL c2,c3,SUM(amount)
  FROM T
GROUP BY c1,c3
UNION ALL
SELECT NULL c1,c2,c3,SUM(amount)
  FROM T
GROUP BY c2,c3
UNION ALL
SELECT NULL c1,NULL c2,NULL c3,SUM(amount)
  FROM T
GROUP BY NULL

你要不要来挑战一下ORACLE的效率？也就是说你自己把数据读取出来，按这些组合来做聚合运算。注意别用到GROUP BY,否则你还是在借助ORACLE做聚合。

yulihua49

原帖由 newkid 于 2010-2-12 03:22 发表

GROUP BY CUBE 相当于对所有的列组合做聚合运算，然后把这些结果合并起来。假如CUBE里有N个列，就有2^N种组合。

以三个列为例，

SELECT c1,c2,c3,SUM(amount)
  FROM T
GROUP BY CUBE (c1,c2,c3);

相当于:

SELECT c1,c2,c3,SUM(amount)
  FROM T
GROUP BY c1,c2,c3
UNION ALL
SELECT c1,NULL c2,NULL c3,SUM(amount)
  FROM T
GROUP BY c1
UNION ALL
SELECT NULL c1,c2,NULL c3,SUM(amount)
  FROM T
GROUP BY c2
UNION ALL
SELECT NULL c1,NULL c2,c3,SUM(amount)
  FROM T
GROUP BY c3
UNION ALL
SELECT c1,c2,NULL c3,SUM(amount)
  FROM T
GROUP BY c1,c2
UNION ALL
SELECT c1,NULL c2,c3,SUM(amount)
  FROM T
GROUP BY c1,c3
UNION ALL
SELECT NULL c1,c2,c3,SUM(amount)
  FROM T
GROUP BY c2,c3
UNION ALL
SELECT NULL c1,NULL c2,NULL c3,SUM(amount)
  FROM T
GROUP BY NULL

你要不要来挑战一下ORACLE的效率？也就是说你自己把数据读取出来，按这些组合来做聚合运算。注意别用到GROUP BY,否则你还是在借助ORACLE做聚合。

学习了，多谢。
你还是没理解DAU，DAU是帮助你写SQL语句，这语句DAU完全能写出来并映射到结构。
DAU的新发展：利用元数据自动构建模板和数据结构。
元数据(cube.meta)：
TEMPLATE cube 4
c1:=CH_CHAR 28
c2:=CH_CHAR 28
c3:=CH_CHAR 28
sum(amount) sum:=CH_INT
T
---------------------------------------------
mktpl <cube.meta

元文件生成了数据结构 cube_stu和模板cube_tpl，把他们包含到你的C程序中。然后：

cube_stu cube;
DAU cube_DAU;
int ret;
char stmt[4096];
                 DAU_init(&cube_DAU,SQL_Connect,0,&cube,cube_tpl);
                 sprintf(stmt,"GROUP BY CUBE (c1,c2,c3)");
                 ret=DAU_prepare(cube_DAU,stmt);
//if ret == 0
                 while(!DAU_next(&cube_DAU)) {
                          //使用你的cube结构吧
              }
                  DAU_free(&cube_DAU);

DAU帮助你使用ORACLE的一切优秀特性，为什么要回避ORACLE？

[ 本帖最后由 yulihua49 于 2010-2-15 22:18 编辑 ]

newkid

原帖由 yulihua49 于 2010-2-15 22:01 发表

学习了，多谢。
你还是没理解DAU，DAU是帮助你写SQL语句，这语句DAU完全能写出来并映射到结构。
DAU的新发展：利用元数据自动构建模板和数据结构。
元数据(cube.meta)：
TEMPLATE cube 4
c1:=CH_CHAR 28
c2:=CH_CHAR 28
c3:=CH_CHAR 28
sum(amount) sum:=CH_INT
T
---------------------------------------------
mktpl  

呵呵，我理解你的DAU是为你那种编程风格服务的。应该说是OO在怂恿你用C语言挑战ORACLE的CUBE, 我就添油加醋一把。
我不理解的是你这“帮助写SQL”到底帮了什么，你写这个模板的工作量已经不比写SQL小。而且把GROUP BY割裂到后面去了，可读性大大下降。
"为什么要回避ORACLE"这个我完全赞成，我不但不回避而且要把尽可能多的编程工作用ORACLE来实现，让这个DAU无用武之地。

yulihua49

原帖由 newkid 于 2010-2-16 04:13 发表

呵呵，我理解你的DAU是为你那种编程风格服务的。应该说是OO在怂恿你用C语言挑战ORACLE的CUBE, 我就添油加醋一把。
我不理解的是你这“帮助写SQL”到底帮了什么，你写这个模板的工作量已经不比写SQL小。而且把GROUP BY割裂到后面去了，可读性大大下降。
"为什么要回避ORACLE"这个我完全赞成，我不但不回避而且要把尽可能多的编程工作用ORACLE来实现，让这个DAU无用武之地。

自SQL问世，能够把结果集与C结构对应起来，能够把结构与SQL语句结合起来，是无数C程序员的梦寐以求。程序与数据独立，是编程的最高境界。JAVA问世没几年，就解决了ORM问题，这就说明，Relation 多么迫切与 Object 做Mapping。C，由于它的先天特点，数十年来没有解决Struct与Relation的Mapping问题。现在，用C访问数据库，已经被JAVA人士看不起，认为太痛苦了。但事实上，C程序的高性能仍然是JAVA难及的，许多高性能系统仍需要C程序来解决。C语言便捷访问数据库问题必须解决。在JAVA中，集合数据的工具是对象，而在C中，集合数据的工具是struct。如果在应用函数间互相传递数十个变量，处理起来是太繁琐了。在DAU之前，如果与SQL的DAO通信，每一个数据结构都是一个单独的函数，把读到的列、变量逐个赋值到特定结构的成员中，程序冗长繁琐易错，而且数据完全不独立，每一个少许数据修改都涉及大批的程序。你说这个问题应该如何解决呢？
   C的struct是不可解析的，它注定不能象JAVA那样用反射机制来访问未知的Object（当然，反射访问效率是很低的）。那么模板就成为访问未知struct的唯一手段。经过几十年来无数C工作者的努力，出现了种种映射结构的方法，但没有哪种方法能够全面的在SQL与struct间建立完整的联系。DAU是在这方面的一个尝试。
   你不能单独从一个语句中看程序是繁了还是简了（这要从全体来看）。我们定义了一个模板，它的应用是多方面的，如果与PRO*C做一个对比：对一个SQL中涉及的列，变量定义时要描述一遍，SQL中还要描述一遍，into子句或绑定变量再描述一遍，最繁琐的，在结果集出来后装载结构时还要描述一遍。这就远比DAU复杂了。而且所有这些完全数据相关的，数据的任何变化都要改程序。比如，上述例子，c2改成数字型，c3改CHAR（50)，再增加一个avg(amount)列，DAU只要改元数据，然后重新编译程序即可。PRO*C可就要大片修改了。数据列数越多，DAU的优势越明显。
    在那个 //处理你的cube结构的代码段里，我可以有非常丰富的功能，如结构打包成字符串或JSON对象或XML对象（这就是一句话，没模板你试试），也可以进行FFT分析，甚至对GIS地图库进行标注。。。这时，结构和模板都得到使用。
    你只说一个SQL语句，是简单，但只能用一次。而模板是一次定义多次使用的，贯穿整个应用逻辑。自动生成的语句出现在日志里，可以粘到sqlplus里执行，调试是非常方便的，PRO*C是做不到这个的。很容易搞清楚语句与模板的关系，模板的哪一部分与语句的哪一部分对应，如何把语句分解成模板都是很简单的，搞清这个规则，程序是很好懂的，甚至比完整的SQL语句都好懂。象上边的例子，select 4个列，都是什么，从哪个表，有什么条件。。。。一个比较复杂的问题分解成一系列简单问题。
   DAU的设计目标是在C环境下能够把一切SQL语句映射到结构。但我知道有些语句不行，这就是我从前说的20/80法则，你可以在DAU环境下直接使用sqlora，这种情况不会很多。DAU是为C程序服务的，不是与存储过程竞争的，虽然在同等条件下我并不认为它的性能比存储过程差。所以，怂恿你用C语言挑战ORACLE的CUBE？我为什么要挑战？我直接用CUBE，你能用什么我就能用什么，不存在挑战问题，DAU就是个工具，想凿哪个凿哪个。
   所谓我那个风格，就是通用函数的风格，就是程序与数据独立的风格，就是程序可移植的风格。换句话说，不管你是什么数据，都是那么几个函数，你很简单的学会这几个函数，剩下的，需要研究的是怎样把语句分解成模板，其中单个表的模板可以自动生成，不需要你去分解。语句的分解具有十分简单的逻辑：模板是列表达式和表表达式，程序中是条件表达式。然后DAU帮你组建语句，绑定变量，扩展日期时间类的函数及格式表达式，扩展表属主。帮你保留游标（比软软解析快n倍哦）。最后，帮你把结果集逐行解析到结构。还有，如果使用不易理解的列名，程序和模板可以转换成可理解的，如果你使用带大小写的列名，可以帮你加引号。如果是单表复合主键访问，你什么都不用写了，全帮你办了。如果需要还可以帮你把结构打包成字符串或JSON，这可是通信必须的哦。

    DAU的宗旨，简化编程易学易用，提高程序的性能和可靠性，程序的柔软性。

[ 本帖最后由 yulihua49 于 2010-2-16 22:43 编辑 ]

newkid

"程序与数据独立，是编程的最高境界。" 我反对，有些程序是可以独立的，比如输入输出格式化、与其他系统通讯等。数据处理、集合操作等应该让数据库来完成。至于独立于数据库的应用为什么不可取，前面已经讲过了，如果做出来必然以牺牲性能为代价，必然把一个高端数据库降格到与山寨产品持平的水准。

你这个DAU的种种好处，如果局限于上述讲的应用范围，如你说的JSON和XML处理，我完全赞成。我不赞成的是程序员以为用了这个东西就把数据库当成一个存储设备，可以不了解数据库的运作原理，可以不掌握SQL, 把所有表连接都变成了嵌套循环，把一些数据库本来具有的功能（比如分析函数，比如CUBE）又用C语言实现了一遍还美其名曰“独立”。如果真像你所说“你能用什么我就能用什么”，那么剩下给DAU的事情真的不多了。

“比软软解析快n倍哦”你说的是和PLSQL的软软解析相比？有测试例子表明快n倍吗？

yulihua49

原帖由 newkid 于 2010-2-18 00:00 发表
"程序与数据独立，是编程的最高境界。" 我反对，有些程序是可以独立的，比如输入输出格式化、与其他系统通讯等。数据处理、集合操作等应该让数据库来完成。至于独立于数据库的应用为什么不可取，前面已经讲过了，如果做出来必然以牺牲性能为代价，必然把一个高端数据库降格到与山寨产品持平的水准。

你这个DAU的种种好处，如果局限于上述讲的应用范围，如你说的JSON和XML处理，我完全赞成。我不赞成的是程序员以为用了这个东西就把数据库当成一个存储设备，可以不了解数据库的运作原理，可以不掌握SQL, 把所有表连接都变成了嵌套循环，把一些数据库本来具有的功能（比如分析函数，比如CUBE）又用C语言实现了一遍还美其名曰“独立”。如果真像你所说“你能用什么我就能用什么”，那么剩下给DAU的事情真的不多了。

“比软软解析快n倍哦”你说的是和PLSQL的软软解析相比？有测试例子表明快n倍吗？

模板系统处理，必须是全过程的。你要想用一个模板解析一个结果集，他的语句是同一个模板生成的，才是绝对可靠的。否则你要仔细语句和结果集与结构模板的关系。包装最好包的严严实实，免得不协调。DAU不牺牲效率，它比大多数二、三流程序员的效率高。
退一步说，DAU附加的开销非常小，可以忽略不计。
按你所说，好容易写了一个模板，只解决一部分问题，语句还要自己写多不值啊！事，已经费了，就一并把语句也解决了吧。
我一再一再的发帖说明，DAU可以写一切语句，你的集合啊，分析啊，cube啊在DAU里尽管用。你驳的都没在点上。

独立，也有程度的区别，独立到什么程度。独立性越高就越通用。

下面这帖说的问题，我的加载器就解决了，他那些SQL语句肯定没有帮定变量，效率不行的。我前边说的加载卸载器，既可以大文件，又有高效率（我可以说是以提高性能为代价），就是独立的效果。独立程序效率高不高，要看水平，不能一概而论。
sqlldr是数据独立的，DAU也是，性能都不低，各自面向不同的问题。
http://www.itpub.net/thread-1266217-1-2.html

你用软软解析的方式和不解析的方式试一下好啦。
我测的是2.5,不是说C与存储过程比，而是解析语句与不解析语句比。
你完全可以试一下，用普通的插入语句（软软解析）。
开一个游标，不断用游标插入，中间不关闭，弄个几万记录试试。当然后一种程序比较麻烦，很少有人这么搞。

[ 本帖最后由 yulihua49 于 2010-2-22 15:11 编辑 ]

newkid

"模板系统处理，必须是全过程的。你要想用一个模板解析一个结果集，他的语句是同一个模板生成的，才是绝对可靠的。否则你要仔细语句和结果集与结构模板的关系。包装最好包的严严实实，免得不协调。DAU不牺牲效率，它比大多数二、三流程序员的效率高。"
我和许多前台开发人员合作过，大家调用存储过程后访问输出游标，既不用映射结构也不用ORM, 因为访问结果集的目的只是简单的格式化、输出。
你一心想要拿到数据后再做事务处理，所以你才有这个需求，所以你才发明了DAU为你这种思路服务。
一旦把事务处理转给存储过程完成，你这DAU用处就很小了。存储过程才是最好的数据库包装器。


"按你所说，好容易写了一个模板，只解决一部分问题，语句还要自己写多不值啊！事，已经费了，就一并把语句也解决了吧。
我一再一再的发帖说明，DAU可以写一切语句，你的集合啊，分析啊，cube啊在DAU里尽管用。你驳的都没在点上。"
我用存储过程，所有数据库的特性都可以很方便地使用。你的DAU虽然也可以应用于任何SQL, 但就如前面的例子, 一个SQL被肢解得支离破碎，不堪卒读。

"独立，也有程度的区别，独立到什么程度。独立性越高就越通用。"
那你说“越通用”就越好吗？你愿意用ORACLE的CUBE还是自己实现CUBE?

"下面这帖说的问题，我的加载器就解决了，他那些SQL语句肯定没有帮定变量，效率不行的。我前边说的加载卸载器，既可以大文件，又有高效率（我可以说是以提高性能为代价），就是独立的效果。独立程序效率高不高，要看水平，不能一概而论。
sqlldr是数据独立的，DAU也是，性能都不低，各自面向不同的问题。
http://www.itpub.net/thread-1266217-1-2.html
"
我已经回了一贴，这个问题就该用SQLLDR解决。
你最得意的“映射到结构”在数据加载中没有什么用对吧？

"你用软软解析的方式和不解析的方式试一下好啦。
我测的是2.5,不是说C与存储过程比，而是解析语句与不解析语句比。
你完全可以试一下，用普通的插入语句（软软解析）。
开一个游标，不断用游标插入，中间不关闭，弄个几万记录试试。当然后一种程序比较麻烦，很少有人这么搞。
"
那贴楼主用的“普通的插入语句”连绑定变量都没用，谈何“软软解析”？
PLSQL的软软解析是全自动的，绑定变量也是全自动的，不绑定才费劲呢，我根本不必操那份心。

yulihua49

我已经回了一贴，这个问题就该用SQLLDR解决。
你最得意的“映射到结构”在数据加载中没有什么用对吧？结构是数据总线，一切通过结构。
全独立程序使用隐结构，不是编程时定义的，而是一种结构布局的存储区。SDBC提供隐结构的存取。
如：
     ret=DAU_init(&_DAU,SQL_Connect,tablename,0,0);//从数据库读表结构，形成虚结构和模板。
。。。。。。
     fgets(buf,sizeof(buf),fd); //从文件读一行
     DAU_dispack(&_DAU,buf); //内容拆包到虚结构
     ret=DAU_insert(&_DAU,buf); //形成语句（只第一次执行），在虚结构绑定变量（要处理null状态变化），执行。
     if(ret != 0  && SQL_Connect->Errno == DUPKEY) {
               *buf=0;
               ret=update_by_PK(&_DAU,buf);
.......
       }
。。。。
      DAU_free(&_DAU);

这时，我们不知道表和数据结构，影响对程序功能的理解吗？
如果一定要你写一个此类的通用处理，你怎么办呢？我相信你能写出来，不过要复杂得多。我稍加修改就可以写出很多派生程序满足各种不同需求。
我们有很多这样的程序，把一个系统的若干表加工加载到另一个系统的若干表，而且是异构数据库。


"你用软软解析的方式和不解析的方式试一下好啦。
我测的是2.5,不是说C与存储过程比，而是解析语句与不解析语句比。
你完全可以试一下，用普通的插入语句（软软解析）。
开一个游标，不断用游标插入，中间不关闭，弄个几万记录试试。当然后一种程序比较麻烦，很少有人这么搞。
"
那贴楼主用的“普通的插入语句”连绑定变量都没用，谈何“软软解析”？
PLSQL的软软解析是全自动的，绑定变量也是全自动的，不绑定才费劲呢，我根本不必操那份心。
普通的就是自动绑定的，不操心的那种。
你试试开游标的，需要操心的那种，比比效率。

关于支离破碎，那是思想方法的问题，你习惯一种方法，别人习惯另一种方法，入乡随俗的事。
你看hibernate，不就是搞了个HQL吗？我就是学他，相当于HQL。HQL就是支离破碎，大家也很接受。
思维方法换一下，海阔天空。
看模板时，知道此表如此。
看程序时，如此访问此表。逻辑很清晰。

另外你给的那个席位发布程序，空表可以工作，已经有数据会出错，有空请帮看看。

[ 本帖最后由 yulihua49 于 2010-2-24 10:05 编辑 ]

newkid

如果仅仅是数据加载，不涉及任何事务处理逻辑，映射到结构就没什么意义，一个二维数组就够了。你需要的只是一个缓存，从文件读入，再送给目标数据库。
通用的数据抽取转换工具已经很多了，我只要使用就行。

你的意思是手工处理游标更快？等我有空比较一下。

hibernate我们是不用的，看不到任何好处。我们大量使用存储过程。

看模板时，知道此表如此。----- 如果有聚合，或者多表连接，你就不能用表模板了，你看到的已经不是表结构了
看程序时，如此访问此表。逻辑很清晰。------- 同上，如果是复杂SQL，你还得回头再去看模板才有意义。

可见用了你的DAU,你就会培养出一堆只知道单表操作的程序员。

那个席位发布程序报什么错？让它出错的运行步骤是什么？我自己的测试结果（连续运行两次程序），第二次什么数据也不产生而且不报错。