预计算的时代该结束了

[Braisdom]

原文链接： https://www.agiquery.com/blog/precomputation-should-be-over

[Magentaize]

Agile Query 完全不需要数据预计算

不一定，针对超大数据量，或者过度个性化的分析，建议通过物化视图的方式预先处理数据，Agile Query 依然可以集成。

[Braisdom]

@sampeng DSL 不是核心，算法是核心

[Braisdom]

@sampeng 你只提到了预计算的优点，还要看到缺点。

[lexa]

@Braisdom 哪些算法呀？

[Braisdom]

写在 BP 里的：

• 过度计算识别算法
• 编译器相关算法
• 数据分析意图识别算法

[lexa]

@Braisdom 有解释不，理解起来有困难啊

[Braisdom]

@lexa 后面写文档说明一下，可能会晚些时候

[JavaGo]

@Braisdom 期待中...

[encro]

坐等 PG 物理视图出来

[iugo]

君子爱财, 取之有道.

@lexa 现在是没有做评论隐私保护的, 可以看到 @lexa 现在的所有评论都是在 "捧" Agile Query, 而没有参加任何社区的其他讨论. 因此, 我认为 @lexa 是一名水军或小号.

我认为这是一种错误的营销方式.

[Braisdom]

@iugo 被你发现了，是我之前公司的同事，

[meeop]

看起来只是提供了一些语法糖包装 sql,底层还是普通 sql?

那和标题的预计算有什么关系,并没有预聚合任何数据啊

[Braisdom]

@meeop 预计算的优点之一是降低 SQL 的复杂度，用了 Agile Query 就不用考虑 SQL 的复杂度了。

[SingeeKing]

只有我更好奇原来的地址是什么吗

[KevinShiCN]

@Braisdom
我是从别的帖子看到你的项目，点进来看了你的网站和一些回复
就拿 RFM 分析来说
我通过 FineBI 的这个纯界面的方式也能快速实现 RFM 分析
https://help.fanruan.com/finebi/doc-view-703.html

截止到目前我并没有看到 Agile Query 比 FineBI 更先进的地方
既没有帮我更智能的清理数据、也没有更高效的产品体验

希望可以帮助我（以及其他用户）梳理一下这方面的差异

[Braisdom]

@KevinShiCN 可能你没用 FineBI 做过 RFM 分析吧，如果是多张表的时候，用户表，订单表，订单明细表的时候，用 FineBI 怎么快速做呢。

[Braisdom]

@KevinShiCN 还有 RFM 只输出一个分类，如果再增加近 30 天的订单数量 ，销售情况，购买其它商品的销售情况，FineBI 又是怎么做的呢。