📄 88.txt
字号:
发信人: fervvac (高远), 信区: DataMining
标 题: Re: 突然发现
发信站: 南京大学小百合站 (Sun Sep 22 17:32:43 2002), 站内信件
If both approaches are well optimized, DB-base approches will deffinitely
be much slower. Do NOT be misled by vendors, DB is scalable solution,
not the fastest/most efficient solution.
Besides, each run of your sql statement does the computation from scratches,
i.e., ther is no sharing or coordination amont them.
Furthermore, wihtout (covering) index, the only access method of such
a query at each run is table-scan. So your approach is O(2^n) table
scan. Forget about it.
【 在 highso (漫步者) 的大作中提到: 】
: 怎么会爆呢?sql执行的速度还是很快的,而且n不是很大,
: 这样作的效果还可以,用fp-tree反而速度很慢:(
: 【 在 joe (十三) 的大作中提到: 】
: : 哦?那你是不是对每一个可能的频繁项集都计算支持度啊?
: : 假设每个属性有n个值,
: : 那么可能的频繁1项集有n个,可能的频繁2项集有n^2个。。。
: : 那么总的可能有n + n^2 + n^3 +....
: : 哈哈,你的机器要爆了。
: : Apriori算法是对上述搜索空间进行剪枝。他跟sql并不矛盾。
: : 你当然可以用sql实现一个apriori算法。
--
※ 来源:.南京大学小百合站 bbs.nju.edu.cn.[FROM: 饮水思源BBS]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -