@lichao 您知道下面这条表达式生成的 SQL 有多少行吗？：

SELECT
COUNT_IF(GROUP_COUNT(orders.order_id, customers.customer_id) > 2) AS "复购客户数量",
categories.category_name AS "品类（指定关系）",
GROUP_SUM(order_details.quantity * order_details.unit_price, categories.category_name) AS "品类销售额",
SUM(order_details.quantity * order_details.unit_price) AS "销售额"
FROM "329875" LIMIT 2000

@dc2002007 数据关系是预定义的，不需要每次查询时指定，当然也支持动态关系

@Braisdom
@dc2002007
@lichao
@justdoit123
对上面的 DSL 你们会拒绝使用吗？

@dc2002007
上术 SQL 涉及了 orders ，customers ，categories ，order_details ，categories 这些表，
这些表的连接你完全不用关系，内部的子查询也是自动生成的，输出的数据符你的要求。

上述 SQL 可以直接出结果

你的 SQL 可以写成这样，不用关心多表连接，聚合函数可以嵌套：

SELECT
COUNT_IF(GROUP_COUNT(orders.order_id, customers.customer_id) > 2) AS "复购客户数量",
categories.category_name AS "品类（指定关系）",
GROUP_SUM(order_details.quantity * order_details.unit_price, categories.category_name) AS "品类销售额",
SUM(order_details.quantity * order_details.unit_price) AS "销售额"
FROM "329875" LIMIT 2000

之前的贴子里已经讲到过，Agile Query 没有设计新的语法，和 SQL 一模一样，唯一的不同是多了大量分析型函数而已，通过这个函数，使用者不要关心 『多表聚合运算』。

@locoz V2EX 只是一个渠道而已，不是唯一的渠道。指出产品的不足没关系，担心的是完全没看过产品，然后就在这里评论
如果看了还不了解，我可以修改文档，在贴子里回复，

@lichao 每个人的偏好不一样的，很难强求的。

@zvvvvv 目前面向企业客户，个人用户暂时还不开放。

@hero0earth 学习了一下，感觉不错，点赞。

@Nile20 你说的当然正确了，我想表达的是产品的初期是很容易被扼杀的，大家多一些宽容，因为每个产品都是从初期发展起来的，就像我们面对刚毕业的大学生，多一些宽容更好。

@leonhao

2 ） MPP 的性能也相对的，相比 5 ，6 年前的 MySQL 和 PG ，现在的 MPP 数据的查询性能要高出几百倍了。

@leonhao
1 ）复杂 SQL 的难度是相对的，如果是 SQL 的高手，相信再复杂的 SQL 也不难，关键没有那么多高手，也不好找。
2 ） MPP 的性能也相对的，相比 5 ，6 年前的 MySQL 和 PG ，现在的 MPP 数据的查询性能要调出几百倍了。

@fishily1993 你说的非常对，坚持和执拗不是一墙之隔，是一回事。懂得坚持的人往往更酷一些

@weijancc Agile Query 没有定义语法，语法与 SQL 完全一致，只是新增了大量分析函数，你可以先简单了解一下 Agile Query

还有，在喷其它人的项目的同时，自己可以好好想想，自己能不能坚持 3 个月，半年搞一个小东西，做出来的东西敢于发出来让人挑战吗？

@sampeng 我个人对每个技术人做的产品都保持着敬畏之心，无论是创业项目，还是个人兴趣，因为任何一个项目没个 3 个月，半年是搞不出来的，能潜下心来认真做一件事，实属不易。

@CaptainD
1 ）数据量大小其实并不重要，关键看分析的复杂度，如果复杂高，写 SQL 是有难度的，而且维护起来也比较复杂，Agile Query 本质上是降低 SQL 的复杂编程，如果你的统计需求原本就很简单，那就不需要 Agile Query ，用 Excel 就能做了。
2 ） Agile Query 有个大前提是 MPP 数据库的发展，使得大数据量的复杂 SQL 也可以正常查询了，而且效率非常高。
3 ）数据清洗在早期已经完成了，而分析需求是不断的新增的，这样的工作是持续的，没有尽头的，如果每个分析需求都有 300-500 行的 SQL ，维护成本是极高的。