这是一个创建于 305 天前的主题，其中的信息可能已经有所发展或是发生改变。
1 ）大家对 DSL 普遍感到鄙视，认为作用不大，实现难度也不高 其实所有高级编程语言都是 DSL ，只不过是语言的特性多与少，Agile Query 的确设计了一种新的 DSL ，但也有程序编译的所有过程，从词法 -> 语法 -> 语义 -> IR -> 有向无环图，最终构建所有子查询，再优化子查询，输出 SQL 。
2 ）对 BI 的认知误区 感觉 BI 系统就是要一层一层构建中间数据，这符合程序员的思维，将复杂问题分解成多个问题，逐个解决。Agile Query 提出了一种新的方式，将复杂的过程封装起来，外部无法感知而已，并不是复杂问题不存在了。
 |
1
wenhuacode 305 天前  1
power bi 很方便
|
 |
2
Braisdom OP @wenhuacode 对的，的确很方便。
|
 |
3
justdoit123 305 天前
我自己觉得 DSL 多了，要记的东西就太多了。不同的 DSL ，等于有不同的编程语法。
但是矛盾就在于，DSL 本质上是沉淀的结果，总不能每次写个新东西都从二进制开始吧？ 只能说希望同领域、同场景的 DSL 语法最好趋于相近，能有一个统一；不同领域、不同场景的 DSL 的语法，能遵循一定的规律。 |
 |
4
beneo 305 天前 6
1. 不是鄙视 DSL ，是反感你的人设和执拗；一个人坚持搞了大半年的 Agile Query ，这种努力值得尊重。但是，一开始大谈特谈自己不是 BI ，结果最后还是 BI ，开始说要开源最后没影，开始说 Docker 本地试用，现在都烟消云散，你一开始就不要立 Flag 嘛。你的算法再牛，现在看上去核心卖点还是 DSL ，也不敢直接秀出来，藏着掖着，直接网页注册试用啊。哎哟你这东西多金贵，还天天怪大家思想跟不上你。
2. 然后咱们聊聊 BI 。你可能觉得大家对 BI 有什么误解，但实际上，大家用 BI 的不少，用 BI 交付项目的也不少。在这个圈子里，操作的便利性，向上管理的艺术，以及数据的处理能力才是王道。你的 Agile Query 提供了新的 DSL ，挺好，但问题来了，如果大家已经用着 FineBI 、QuickBI 、PowerBI 挺顺手的，为啥还要折腾去用你的东西？你说的这些语法糖真的解决了什么实质性的痛点吗？什么过度计算在企业里面真的会算个大问题么？就像你家做的厕纸更薄更有韧性，减少成本 5%，但是对使用手法有了更高的要求，那这点改进真的值得大家换吗？ 说白了，你这个坚持，论谁都提倡都点赞，但你不吹牛没有人捶你，你有东西就秀出来，别搞了快一年了，时不时跳出来说你这个东西有多好多好，但是你们想看啊，来联系我吧。哎呀，兄弟，你要营销真发错地方，真累 |
|
5
Braisdom OP @justdoit123 习惯有时是个好东西，有时候反而会局限自身的认知，好奇一些往往会有意想不到的收获。
|
|
7
Braisdom OP @beneo 我不是开源项目，不需要有人点赞，只是让更多人看到，其中找到需要的人而已，如果你真的对项目感兴趣，可以加我微信，而不是在贴里讨论。
Agile Query 不能满足所有人的需求，但肯定能满足一部分人的需求，我需要的是让那部分人看到，看懂。 |
 |
10
sampeng 305 天前 3
不是。。没别的意思。技术人都是直来直去。。你要吹你的东西多好没问题。别整天想着搞个标题党然后就爆火了。就算是官方博客你即不是行业领袖也不是行业大拿。这个语气和内容完全不匹配。
想赚钱没什么寒碜的，光明正大的赚光明正大的打广告爱看的就看一眼，不爱看的就划过了。 |
 |
11
CaptainD 305 天前
我简单看了您的几篇文章，有点疑问
1. 如果数据量比较小的情况下，我本身就不需要预计算，直接写 SQL 似乎更好，为什么要用一个新语法 2. 如果数据量很大，依然需要预计算的话，Agile Query 为什么会减少预计算表，它的底层不是基于 SQL 吗 3. 我个人认为分析报告也好，BI 也好，主要的精力不是复杂 SQL ，是各种指标能否正确计算，数据质量是否好，大量精力会用在处理脏数据上 |
|
12
Braisdom OP 1
@CaptainD
1 ）数据量大小其实并不重要，关键看分析的复杂度，如果复杂高，写 SQL 是有难度的，而且维护起来也比较复杂，Agile Query 本质上是降低 SQL 的复杂编程，如果你的统计需求原本就很简单，那就不需要 Agile Query ，用 Excel 就能做了。 2 ） Agile Query 有个大前提是 MPP 数据库的发展，使得大数据量的复杂 SQL 也可以正常查询了，而且效率非常高。 3 ）数据清洗在早期已经完成了，而分析需求是不断的新增的，这样的工作是持续的，没有尽头的，如果每个分析需求都有 300-500 行的 SQL ，维护成本是极高的。 |
|
14
Braisdom OP @sampeng 我个人对每个技术人做的产品都保持着敬畏之心，无论是创业项目，还是个人兴趣，因为任何一个项目没个 3 个月，半年是搞不出来的，能潜下心来认真做一件事，实属不易。
|
|
15
Braisdom OP 还有，在喷其它人的项目的同时，自己可以好好想想，自己能不能坚持 3 个月，半年搞一个小东西，做出来的东西敢于发出来让人挑战吗？
|
 |
16
weijancc 305 天前
DSL 相当于一种异类, 被排斥是正常的, 我本职是写 Java 的, 就很排斥 Rust, 语法接近的 typescript 就马上接受且上手. 你发明 DSL 相当于自己定了个标准, 问题你又没有大厂背书, 谁会那么闲专门去学你的语法呢?
|
 |
19
fishily1993 305 天前 1
有时候，坚持和执拗只有一墙之隔🙄
|
|
20
Braisdom OP @fishily1993 你说的非常对，坚持和执拗不是一墙之隔，是一回事。懂得坚持的人往往更酷一些
|
 |
21
leonhao 305 天前
@Braisdom 你这个前提就错了，首先复杂 SQL 没难度，难的是写出高性能的复杂 SQL 。第二 MPP 数据库大数据量下的复杂 SQL 效率没有非常高，这是分层搞中间表的非常重要的一个原因。
|
|
22
Braisdom OP @leonhao
1 ）复杂 SQL 的难度是相对的，如果是 SQL 的高手，相信再复杂的 SQL 也不难，关键没有那么多高手，也不好找。 2 ） MPP 的性能也相对的，相比 5 ，6 年前的 MySQL 和 PG ，现在的 MPP 数据的查询性能要调出几百倍了。 |
 |
24
Nile20 305 天前
@Braisdom 我对你的产品没有意见，毕竟我不是用户。但是如果你为产品的辩护是“在喷其它人的项目的同时，自己可以好好想想，自己能不能坚持 3 个月，半年搞一个小东西，做出来的东西敢于发出来让人挑战吗”，那可能你在产品推广策略上有一些优化空间。是否选择一款产品，是看它是否能有效解决需求，而不是开发者坚持做了多久。大家需要的是疗效，坚持了多久并不构成护身符。
|
|
25
Braisdom OP @Nile20 你说的当然正确了，我想表达的是产品的初期是很容易被扼杀的，大家多一些宽容，因为每个产品都是从初期发展起来的，就像我们面对刚毕业的大学生，多一些宽容更好。
|
 |
26
lichao 305 天前
SQL 高手完全可以自己写 SQL ；
SQL 低手大概率学不好、也用不好你的小众 DSL |
 |
30
locoz 305 天前
你似乎忽略了一个很关键的问题，就是你的产品本身是面向企业、面向不那么技术人员的人群的，你的主要目标也是企业用户，那你还在 V2EX 这种地方发推广干啥呢？纯纯的吃力不讨好...关键的潜在客户拉不到多少，还得花时间和精力应付挑毛病的，就很没必要。
|
|
31
Braisdom OP @locoz V2EX 只是一个渠道而已，不是唯一的渠道。指出产品的不足没关系，担心的是完全没看过产品，然后就在这里评论
如果看了还不了解，我可以修改文档，在贴子里回复， |
 |
32
dc2002007 304 天前
如果目标是为了写 sql 的话，那直接写 sql 就行，DSL 有点多余了，还得在学习一个新的语法，当然我不是很了解你的软件，若说的不对话可以接受批评。
|
|
33
Braisdom OP 之前的贴子里已经讲到过，Agile Query 没有设计新的语法，和 SQL 一模一样，唯一的不同是多了大量分析型函数而已，通过这个函数，使用者不要关心 『多表聚合运算』。
|
|
34
Braisdom OP 你的 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 |
|
35
Braisdom OP 上述 SQL 可以直接出结果
|
|
36
Braisdom OP @dc2002007
上术 SQL 涉及了 orders ，customers ，categories ，order_details ，categories 这些表， 这些表的连接你完全不用关系，内部的子查询也是自动生成的，输出的数据符你的要求。 |
|
37
Braisdom OP |
|
41
Braisdom OP @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 |
|
43
lichao 304 天前
|
|
47
Braisdom OP @lichao 1000 行 SQL 合不合理是另一个问题，本身我就在持续优化，直到最优，这块相信一定可以解决。
关键是假设 1000 行 SQL 是最合理的，你是愿意维护 1000 行 SQL ，还是 20 行 DSL ？ |
|
50
locoz 304 天前 via Android
@Braisdom #30 主要是一个性价比过低的渠道其实就没啥必要发了，扯皮的时间成本和情绪成本拿去跟潜在客户多聊聊，说不定都能多聊出个订单或者是聊出一些目标客户群体会有的潜在需求。
|
|
52
Braisdom OP V2EX 里的朋友，从开始心态就有一些偏激，一类是过度追捧，一类是过度自我，难得有一些客观的评论，
|
Select Language