这几天想着深入学习下excel与SQL，看到了2篇挺有趣的帖子，都是教你如何在excel里使用sql的。

一个是用python包xlwings，再在vba里打开设置，引用xlwings。后面在excel表格中就可以输入sql语句。

另一个相信大家应该都知道，用的是一个叫ODBC的插件，配置好后，再excel上点击“数据-获取数据-自其他源-从ODBC”。后面再点击高级选项，就可以输入SQL代码了。

不过下面也有人建议用BI工具连数据库，因为用ODBC，即使连上了，把文件发给别人，别人没装ODBC也不能用。

评论区很热闹，有人说：绝了，Excel 终于进化了。也有人鄙夷：这不是舍本逐末吗？

我反而更好奇一个问题：真的有必要在 Excel里写SQL嘛？

Excel，本质是文件。SQL，操作的是服务。

一个是你双击就能打开、拷走、发送的东西；一个是要跑在服务器上，7×24 小时等着你查询的数据系统。

有人打过一个很贴切的比喻：SQL 是火车，Excel 是卡车。

卡车灵活，货不多的时候，说走就走，临时改路线也方便。可一旦货物变多，卡车就开始吃力。

火车前期麻烦，要铺轨道、定规则，成本高。但轨道一旦铺好，每天跑，快、稳。

其实技术上并不新鲜，情绪上很解渴。

ADODB这些东西，十几年前就有了。

但为什么最近又火了？因为大家隐隐约约意识到一件事：Excel 快撑不住了，但我又不想彻底离开它。

于是，SQL 被“塞”进 Excel，成了一种折中方案。

可现实很快泼你一盆冷水：文件一发给同事，对方没装环境，直接不能用；而且最后你会发现你在excel文件里，硬生生模拟了一个系统。

这时候再问一句：如果已经是一整页 SQL、一堆逻辑规则了，为什么不直接上企业管理软件？

既然谈到了企业管理软件，让我们回到企业真实场景。

事实就是，Excel 不够，SQL 也不够。一个管数据，一个管展示，却都不擅长业务逻辑。

这也是很多人开始注意到另一条路的原因，画表格、无代码，直接做业务软件应用。

像 Eversheet（云表）这种国产无代码开发工具，本质不是Excel加强版，而是把 Excel 的易用性和数据库的规范性，揉到了一起。

界面像表格，但不是文件；

业务规则用中文公式和可视化配置完成；

客户端、服务端的数据，都能直接联动。

默认内置数据库，装完就能用。需要更高安全性，可以换国产数据库；

不依赖微软 Excel，有自己的电子表格控件，但兼容 Excel。

每次到这里，总有人跳出来一句：无代码、低代码，都是玩具。

这话10年前也许成立。但现在，更像是没看过现场就下结论。

无代码只是对使用者而言“不写代码”。背后依然是严肃的软件工程，只是被封装起来了。

像恒逸石化，用云表作为数字化操作底座，把过去分散的二十多个系统逐步收拢、复刻、替换。不是为了省程序员，而是为了灵活、可控、能改得动。

这，恰恰是 Excel 和纯 SQL 都很难做到的事。

综上，在 Excel 里用 SQL，不是绝了，也不是原罪。真正的问题是：你是不是在用临时方案硬扛长期的活。

最后，你有什么补充或者修正的地方？

写这些内容花了不少心思，如果对你有帮助和启发，就是我继续更新的动力。谢谢你能看到我的文章，我们下次再见，共同进步！

文 | eamon