写一点最近看回复的感想

[Braisdom]

1 ）大家对 DSL 普遍感到鄙视，认为作用不大，实现难度也不高 其实所有高级编程语言都是 DSL ，只不过是语言的特性多与少，Agile Query 的确设计了一种新的 DSL ，但也有程序编译的所有过程，从词法 -> 语法 -> 语义 -> IR -> 有向无环图，最终构建所有子查询，再优化子查询，输出 SQL 。

2 ）对 BI 的认知误区 感觉 BI 系统就是要一层一层构建中间数据，这符合程序员的思维，将复杂问题分解成多个问题，逐个解决。Agile Query 提出了一种新的方式，将复杂的过程封装起来，外部无法感知而已，并不是复杂问题不存在了。

[wenhuacode]

power bi 很方便

[Braisdom]

@wenhuacode 对的，的确很方便。

[justdoit123]

我自己觉得 DSL 多了，要记的东西就太多了。不同的 DSL ，等于有不同的编程语法。

但是矛盾就在于，DSL 本质上是沉淀的结果，总不能每次写个新东西都从二进制开始吧？

只能说希望同领域、同场景的 DSL 语法最好趋于相近，能有一个统一；不同领域、不同场景的 DSL 的语法，能遵循一定的规律。

[beneo]

1. 不是鄙视 DSL ，是反感你的人设和执拗；一个人坚持搞了大半年的 Agile Query ，这种努力值得尊重。但是，一开始大谈特谈自己不是 BI ，结果最后还是 BI ，开始说要开源最后没影，开始说 Docker 本地试用，现在都烟消云散，你一开始就不要立 Flag 嘛。你的算法再牛，现在看上去核心卖点还是 DSL ，也不敢直接秀出来，藏着掖着，直接网页注册试用啊。哎哟你这东西多金贵，还天天怪大家思想跟不上你。

2. 然后咱们聊聊 BI 。你可能觉得大家对 BI 有什么误解，但实际上，大家用 BI 的不少，用 BI 交付项目的也不少。在这个圈子里，操作的便利性，向上管理的艺术，以及数据的处理能力才是王道。你的 Agile Query 提供了新的 DSL ，挺好，但问题来了，如果大家已经用着 FineBI 、QuickBI 、PowerBI 挺顺手的，为啥还要折腾去用你的东西？你说的这些语法糖真的解决了什么实质性的痛点吗？什么过度计算在企业里面真的会算个大问题么？就像你家做的厕纸更薄更有韧性，减少成本 5%，但是对使用手法有了更高的要求，那这点改进真的值得大家换吗？

说白了，你这个坚持，论谁都提倡都点赞，但你不吹牛没有人捶你，你有东西就秀出来，别搞了快一年了，时不时跳出来说你这个东西有多好多好，但是你们想看啊，来联系我吧。哎呀，兄弟，你要营销真发错地方，真累

[Braisdom]

@justdoit123 习惯有时是个好东西，有时候反而会局限自身的认知，好奇一些往往会有意想不到的收获。

[Braisdom]

@beneo 不是大半年，是 2 年多了，兄弟你估计 Agile Query 的一篇文档都没看完

[Braisdom]

@beneo 我不是开源项目，不需要有人点赞，只是让更多人看到，其中找到需要的人而已，如果你真的对项目感兴趣，可以加我微信，而不是在贴里讨论。

Agile Query 不能满足所有人的需求，但肯定能满足一部分人的需求，我需要的是让那部分人看到，看懂。

[beneo]

@Braisdom 你要的热度效果我帮你添柴了

[Braisdom]

@beneo 感谢。你公司的资料我也看了，我们应该算同行。

[sampeng]

不是。。没别的意思。技术人都是直来直去。。你要吹你的东西多好没问题。别整天想着搞个标题党然后就爆火了。就算是官方博客你即不是行业领袖也不是行业大拿。这个语气和内容完全不匹配。
想赚钱没什么寒碜的，光明正大的赚光明正大的打广告爱看的就看一眼，不爱看的就划过了。

[CaptainD]

我简单看了您的几篇文章，有点疑问
1. 如果数据量比较小的情况下，我本身就不需要预计算，直接写 SQL 似乎更好，为什么要用一个新语法
2. 如果数据量很大，依然需要预计算的话，Agile Query 为什么会减少预计算表，它的底层不是基于 SQL 吗
3. 我个人认为分析报告也好，BI 也好，主要的精力不是复杂 SQL ，是各种指标能否正确计算，数据质量是否好，大量精力会用在处理脏数据上

[Braisdom]

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

[beneo]

@Braisdom 我跟你同行个球，我搞教育的皮包公司而已

[Braisdom]

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

[Braisdom]

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

[weijancc]

DSL 相当于一种异类, 被排斥是正常的, 我本职是写 Java 的, 就很排斥 Rust, 语法接近的 typescript 就马上接受且上手. 你发明 DSL 相当于自己定了个标准, 问题你又没有大厂背书, 谁会那么闲专门去学你的语法呢?

[Braisdom]

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

[weijancc]

@Braisdom 我没看过你的帖子, 只是看你这篇主题自己说了你自行定义了 DSL.

[fishily1993]

有时候，坚持和执拗只有一墙之隔🙄

[Braisdom]

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

[leonhao]

@Braisdom 你这个前提就错了，首先复杂 SQL 没难度，难的是写出高性能的复杂 SQL 。第二 MPP 数据库大数据量下的复杂 SQL 效率没有非常高，这是分层搞中间表的非常重要的一个原因。

[Braisdom]

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

[Braisdom]

@leonhao

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

[Nile20]

@Braisdom 我对你的产品没有意见，毕竟我不是用户。但是如果你为产品的辩护是“在喷其它人的项目的同时，自己可以好好想想，自己能不能坚持 3 个月，半年搞一个小东西，做出来的东西敢于发出来让人挑战吗”，那可能你在产品推广策略上有一些优化空间。是否选择一款产品，是看它是否能有效解决需求，而不是开发者坚持做了多久。大家需要的是疗效，坚持了多久并不构成护身符。

[Braisdom]

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

[lichao]

SQL 高手完全可以自己写 SQL ；
SQL 低手大概率学不好、也用不好你的小众 DSL

[zvvvvv]

@Braisdom #7 两年多了，连个在线试用都没有，一开始还有些期待，但是现在的话真的没必要刷存在感了。用都用不了的东西，我看你文档有什么用。

[Braisdom]

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

[Braisdom]

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

[locoz]

你似乎忽略了一个很关键的问题，就是你的产品本身是面向企业、面向不那么技术人员的人群的，你的主要目标也是企业用户，那你还在 V2EX 这种地方发推广干啥呢？纯纯的吃力不讨好...关键的潜在客户拉不到多少，还得花时间和精力应付挑毛病的，就很没必要。

[Braisdom]

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

[dc2002007]

如果目标是为了写 sql 的话，那直接写 sql 就行，DSL 有点多余了，还得在学习一个新的语法，当然我不是很了解你的软件，若说的不对话可以接受批评。

[Braisdom]

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

[Braisdom]

你的 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

[Braisdom]

上述 SQL 可以直接出结果

[Braisdom]

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

[Braisdom]

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

[dc2002007]

@Braisdom 如果做到了特定数据关系范围的语法简化，那还是很有价值的

[Braisdom]

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

[lichao]

@Braisdom 完全不会考虑使用，理由之前说过了，会 SQL 的人会自己去写，不会 SQL 的人也学不会（大概也不愿意去学）你的 DSL 。

[Braisdom]

@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

[Braisdom]

@lichao 下面是最终编译的 SQL：

[lichao]

@Braisdom 多少行都没有关系，行数多不影响可读性、可维护性。

SQL 有问题可参考的学习资料多如牛毛，你的 DSL 有问题或某方面不理解、不知道怎么写，是不是只能加你微信来请教你？

[lichao]

@Braisdom 看了你贴出来的截图，更加坚信不可能在公司项目上用你的 DSL

[Braisdom]

@lichao OK ，理解了，对您而言，上面的 SQL 如果有 1000 条，甚至更服复杂一些的，也可以进行重用和断点调试了。

[lichao]

@Braisdom 如果你的 DSL 可以 20 行 DSL 编译成 1000 行 SQL ，那么这 1000 行 SQL 大概率极其不合理

[Braisdom]

@lichao 1000 行 SQL 合不合理是另一个问题，本身我就在持续优化，直到最优，这块相信一定可以解决。

关键是假设 1000 行 SQL 是最合理的，你是愿意维护 1000 行 SQL ，还是 20 行 DSL ？

[Braisdom]

@lichao 即使人肉优化 SQL 也是逐步优化的，只不是我把它变成了机器算法而已

[lichao]

@Braisdom 不想回答可能性极低的假设

[locoz]

@Braisdom #30 主要是一个性价比过低的渠道其实就没啥必要发了，扯皮的时间成本和情绪成本拿去跟潜在客户多聊聊，说不定都能多聊出个订单或者是聊出一些目标客户群体会有的潜在需求。

[Braisdom]

@locoz 非常同意

[Braisdom]

V2EX 里的朋友，从开始心态就有一些偏激，一类是过度追捧，一类是过度自我，难得有一些客观的评论，

[lichao]

@Braisdom 既然 V 站网友有这么多问题，是不是可以考虑不在 V 站频繁发推广了