用c实现group by cube的思路

yulihua49

原帖由 〇〇 于 2010-2-20 21:32 发表
我没有newkid看到的执行计划多，而且我的测试cube（无并行）比union慢

如果一定要处理null，建议：
1。去掉primary key
2.所有类似 *node.c1=0; 都改成：
strcpy(node.c1,"\b");
用单一的退格符做归并标志。空串做null标志。
如果是数字类型的，你可以把n个表示器放进树节点，比较器对表示器进行适当的处理即可。
二叉树程序在我给你的blog里有，你下载编译用吧，试试看，哪种方法快。
当然，数据库的访问你用习惯的方法完全可以。

附带说一下，在C里边，处理ORACLE的number类型，可以使用decimal对象，但效率是相当低的，通常还是变成C的int，long，short，double来处理，这时null我通常用一个不常用的值来代替，这样处理问题简单一些，比使用表示器方便。SDBC把null的处理包含在内，对程序员透明了。

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

〇〇

是http://space.itpub.net/8804348/ 么?

yulihua49

原帖由 〇〇 于 2010-2-22 11:27 发表
是http://space.itpub.net/8804348/ 么?

见本帖5楼。

newkid

原帖由 yulihua49 于 2010-2-22 11:05 发表

如果一定要处理null，建议：
1。去掉primary key
2.所有类似 *node.c1=0; 都改成：
strcpy(node.c1,"\b");
用单一的退格符做归并标志。空串做null标志。
如果是数字类型的，你可以把n个表示器放进树节点，比较器对表示器进行适当的处理即可。
二叉树程序在我给你的blog里有，你下载编译用吧，试试看，哪种方法快。
当然，数据库的访问你用习惯的方法完全可以。

附带说一下，在C里边，处理ORACLE的number类型，可以使用decimal对象，但效率是相当低的，通常还是变成C的int，long，short，double来处理，这时null我通常用一个不常用的值来代替，这样处理问题简单一些，比使用表示器方便。SDBC把null的处理包含在内，对程序员透明了。

你这方法不怎么样。我前面说了，NULL是无可替代的。这里要解决的是区分数据本身的NULL和CUBE组合中产生的NULL, 我给你指出两条明路：
方法1. 引进一个虚拟列，它的值从000到111不等，其实就是把GROUPING函数实现了。这样你的键就变为四个列，各种NULL也就不会混淆。
方法2. 设计8棵树，各管各的数据，反正输出才需要合并。好处是很多树不需要比较三个列，这样就提高效率。

如果真要实现CUBE, 还有很多好玩的思路，除了你的二叉树(SORT GROUP BY), 以及前面说过的HASH GROUP BY, 还可以试试 ROLLUP， 即在前面聚合的基础上再聚合。

yulihua49

原帖由 newkid 于 2010-2-22 23:34 发表


你这方法不怎么样。我前面说了，NULL是无可替代的。这里要解决的是区分数据本身的NULL和CUBE组合中产生的NULL, 我给你指出两条明路：
方法1. 引进一个虚拟列，它的值从000到111不等，其实就是把GROUPING函数实现了。这样你的键就变为四个列，各种NULL也就不会混淆。
方法2. 设计8棵树，各管各的数据，反正输出才需要合并。好处是很多树不需要比较三个列，这样就提高效率。

如果真要实现CUBE, 还有很多好玩的思路，除了你的二叉树(SORT GROUP BY), 以及前面说过的HASH GROUP BY, 还可以试试 ROLLUP， 即在前面聚合的基础上再聚合。

怎么无可替代？ORACLE怎么干的？
带表示器是null的终极解决方案。null的是一组节点，非null是另一组。
但我觉得不需要那么复杂，解决一般需求就可以，谁一定要钻牛角尖，把问题搞得无比复杂而后快？

〇〇

还是出一个挑战赛见
http://www.itpub.net/thread-1271979-1-1.html

newkid

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

怎么无可替代？ORACLE怎么干的？
带表示器是null的终极解决方案。null的是一组节点，非null是另一组。
但我觉得不需要那么复杂，解决一般需求就可以，谁一定要钻牛角尖，把问题搞得无比复杂而后快？

像你试图用\b代替NULL来和其他NULL以示区别是不行的，NULL就是NULL, 你不能用任何数据来取代它。
“表示器”是什么意思？就是加个标志位表明是否为NULL？
就算你用你的“表示器”把NULL表示出来了，你还是没有解决GROUP BY CUBE里面多行重复数据的问题，因为你的程序会把所有的NULL并到一起，你没有区分数据本身是NULL或者GROUPING产生的NULL. 我那两种方法就是为了解决这个，如果你看懂了就会发现其实是很简单的。
这不是钻牛角尖，这是培养一个程序员用严密的思路解决问题。要图省事就直接用GROUP BY CUBE好了。

yulihua49

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


像你试图用\b代替NULL来和其他NULL以示区别是不行的，NULL就是NULL, 你不能用任何数据来取代它。
“表示器”是什么意思？就是加个标志位表明是否为NULL？
就算你用你的“表示器”把NULL表示出来了，你还是没有解决GROUP BY CUBE里面多行重复数据的问题，因为你的程序会把所有的NULL并到一起，你没有区分数据本身是NULL或者GROUPING产生的NULL. 我那两种方法就是为了解决这个，如果你看懂了就会发现其实是很简单的。
这不是钻牛角尖，这是培养一个程序员用严密的思路解决问题。要图省事就直接用GROUP BY CUBE好了。

你没用过PRO*C？每个变量都带一个表示器，表示null，正常值或溢出（返回时）。OCI也是如此。

"\b"是不出现在数据库里的，只是一个程序标志有何不可？"\b"就是归并出来的null标志，但所有的null都归并到一起了，一般情况也不算错，如果null表示不明，所有不明算一类，可否？

学院派与工程派的区别，工程是折衷，要在性能和成本之间平衡，力求解决问题。
你要求完美，比方你一定要求汽车能原地转圈和平移，以方便入位，可那样成本很高。
工程师给你设计的汽车有一定转弯半径，你如果使用这个汽车就必须按这个车的性能来使用。
我们稍稍给数据加一点限制，可以大幅度简化程序设计并提高效率，并不影响一般使用。你说，我就想在数据库存"\b",自己跟自己找别扭啊。
那我把标志改别的字符，当前字符集没有的，数据库存不了的字符行吗？问题当前，总有办法解决。
归类项是满足用户需求，用户才不懂什么null呢，他会说，按什么地区，按什么民族，按什么党派归类，还可能提出有不明民族，无党派或不明党派的情况。
我们做软件设计的都尽量避免null出现，会给 "无" 或 "不明" 安排代码。

你要追求完美，我告诉你，完美是不存在的，即使是SQL，关系模型也有很多不能表达的东西。我们很多应用数据模型都不能用关系表达。解决方法还是折衷。
所以，很多方法并不等价，但同样解决问题。如果说C解决不了SQL的某些问题，那SQL还解决不了C的许多问题呢，在需要共同完成任务的过程中求同存异，互为补充。
你认为cube好，那就cube，这不需要PK。如果应用别的数据库，人家没有cube，那你还要自己做。那么是否约束一下数据以方便编程还是要折衷一下的。

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

newkid

我确实没用过PRO*C。 如果"表示器"是用来表示NULL的一贯做法，那就应该用，也比\b好。任何数据都可能出现的，你不能假设\b不存在。
"但所有的null都归并到一起了"这没有问题，这也是SQL在对NULL进行GROUP BY 的做法。但是“你还是没有解决GROUP BY CUBE里面多行重复数据的问题”，你把不该归并到一起的NULL都归到了一起。

举个例子说明“应用数据模型都不能用关系表达”？你说的不是多媒体数据（音频视频）吧？

yulihua49

原帖由 newkid 于 2010-2-24 22:53 发表
我确实没用过PRO*C。 如果"表示器"是用来表示NULL的一贯做法，那就应该用，也比\b好。任何数据都可能出现的，你不能假设\b不存在。
"但所有的null都归并到一起了"这没有问题，这也是SQL在对NULL进行GROUP BY 的做法。但是“你还是没有解决GROUP BY CUBE里面多行重复数据的问题”，你把不该归并到一起的NULL都归到了一起。

举个例子说明“应用数据模型都不能用关系表达”？你说的不是多媒体数据（音频视频）吧？

更正一下：应用数据模型不都能用关系表达。
图书正文检索也不行，还有其他的。
层次数据，链式数据也不适合关系，但可以变通使用。折衷啊，性能会损失。
如图论里的径路计算，虽然可以用关系模型，但实在效率不高。
人工智能，知识库。。。。。。
最普遍的，汉字编码的字库、码库、词库，没一个用关系数据库的。
像智能输入，敲一个字母出一个集合，一般都是动态代码树。

比如售票系统，车次-停靠站表。用关系就很勉强，一个表是车次表，一个表是停靠站表，停靠站表按车次、顺号排序多行存储。
检索时二表联合查询，又费事又低效。其实他就是一个数组。或链表。但关系的第一范式就规定每个数据是简单项，元祖和属性的次序不影响结果的正确性。
可是我就是数组，次序很重要。

像TPF，一个基于哈希树的层次数据库干这事就很方便，一个记录头，一堆记录体（车次顺号不需要），一次IO就完事。但它干别的就不灵光了。

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