大家的 SQL 一般怎么管理？

[miaeLKK]

我是每次要查什么就手敲，熟练掌握 select * from...😂

所以就导致编辑器界面有点混乱。之前看有的同事好像敲过的就保存一下，下次查询时先搜有没有这个 sql ，没有再敲。不过后面如果加条件的话，岂不也是混乱？还是说在另一个.sql 文件中？

[weivi]

把常用的 SQL 保存到单独的文件里，加上注释，用的时候直接复制，改改就能用。不常用的就现写

[charlie21]

TablePlus 支持 sql 键入历史查询
https://docs.tableplus.com/query-editor/query-history

[Ayanokouji]

datagrip 有 file 和 console 。常用的用 file 保存，临时的用 console 。

[corcre]

我, CRUD boy, 一般需要保存的 sql 就三种, 一种是用户让我导数据, 我会在 excel 那里加一个 sheet 把语句存进去, 不然下次他让再导一份我都不知道上哪给他整这个 sql 出来, 一种就是改了容易把系统改崩, 那就先存一份备份, 还有一种是 sql 还没写完, 得存起来下次接着写...
至于存哪, 我一般是存 onedrive 的自动上传的目录, 这样电脑坏了也不会丢工作进度, 更细致的管理我这个岗位好像就不需要了
需要写一堆东西才能 select 出来的我可能就直接存成视图了🐶🐶🐶

[opengps]

我都是先打开查看一下，再把查看时候自动生成的 sql 复制出来，去查询那里粘贴修改，目的就是为了少敲那几个“select * from”

[lxqxqxq]

视图？

[Tonnnyma]

作为 sql boy ，根据每次的需求场景命名并带上需求方名称，日期，方便以后查阅；或者根据每次的查询内容概括一个名称保存。

[jevonszmx]

很多工具都带 sql 管理的，比如我最常使用的 navicat ，他就可以保存历史查询，常用的保存了一堆。

[linghan]

常用的查询都保存到一个 sql 文件里

[mytoroto]

datagrip ，我直接在 file 新建 sql ，专门留一两个 sql 文件用来平时的临时查询

[lyxxxh2]

不理解为啥要存 sql,从不存。
工作的话,我一直都是 orm 。
复杂的 sql,不敢想象多难阅读。

[dbit]

orm 复杂的语句真是是灾难,
sql 一般我存到 idea 里,并且用 git 同步

[SaltyMouse]

这个问题我也头疼，之前是会存一些常用的，注释好放在一个 sql 文件里面，如果有临时需要的就在最下面加，一个库一个 sql 文件，但村的 sql 多了也会有找不到的情况，着急的就又手敲语句了。DBeaver 有个好用的功能，输入“SF （关键字）+tab”会自动补全“select * from ;”，这个功能可以减少一部分重复输入，关键字和补全后的语句都可以自定义，但是表名还是得自己输一下。

[boshok]

massCode ，默认 sql 代码片断管理。

[langhuishan]

Obsidian 专门一个目录存放通用 SQL ，Obsidian 全文检索好评

[sunznx]

分享到文档上，和同事一起用，一起维护

[carnivalist]

DataGrip ，常用的保存到 scratch 文件，再用坚果云同步

[redbule]

@lyxxxh2 sql 是通用的，sql 比 orm 更易读

[lyxxxh2]

@redbule

!? 我震惊,无法认同。

[haython]

@lyxxxh2 #19 只用 ORM 的一般都没处理过数据，肯定不理解为什么存 SQL

[qwertyzzz]

@lyxxxh2 #11 keyworlds

[lyxxxh2]

@qwertyzzz
keywords 是同事上个月加的,我基本不会看他们代码,不出 bug 就行。

[lyxxxh2]

@haython
我前几年同事说:复杂的 sql 用不了 orm,我觉得跟着这相似,就是扯淡。
orm 唯一缺陷就是大量数据,性能问题,但这也是可以用 orm 来转为 sql 语句执行的。

[tyrantZhao]

貌似 BE 一般不会写很复杂的 SQL ，大数据写的很多，所以 BE 一般不存。

[zhhqiang]

文件传输助手 - -

[haython]

@lyxxxh2 #23 我可以肯定你没有处理过数据了

[ccw4wcc]

@lyxxxh2 #23 如果让你经常处理一些线上的问题呢，比如要在线上数据库导出一些数据，那不是就得写 sql ，比如线上经常要更新一些数据，这些数据就需要写 sql 关联起来更新，那就需要把之前处理过的 sql 存住呀，下次方便继续改改继续用，如果是常用的代码业务逻辑肯定 sql 和 orm 都可以啊

[Jonz]

Navicat 有个 [创建片段] 的功能，可以把常用 SQL 保存起来，并且通过自定义名称来快捷输入。

比如我经常要连表查询某几张表：
SELECT * FROM AAAA d
LEFT JOIN BBBB dx ON dx.main_id = d.id;

那我就直接选中代码右键-创建片段，然后起个名称，比如 [ss] ，那后面我还需要再复用这个 SQL 时只需要输入 ss ，然后从下拉框选择这个片段，就会自动填充完整的 SQL 了。

SQL 里面也支持用占位符来当成变量，其他的数据库客户端应该也是有类似功能的，可以参考看看。

[lyxxxh2]

@ccw4wcc
很简单的我当然是一个 sql 。
大部分时候我都是用代码来修复数据,有个回查的地方。

至于 sql 关联,这我擦 不就是 orm 强项吗?
项目模型本身就做好关联了。

存 sql 方便以后用,不晓得。
反正我一次性代码执行完,基本不会再次执行,都会删掉。

[andytao]

[袋鼠数据库工具] 支持缓存 SQL ，还支持保存 SQL 脚本，然后自动化列在文件列表种，双击即可打开，玩得飞起。。。

[andytao]

[袋鼠数据库工具] 支持有三种 SQL 保存方式：
1 、支持缓存 SQL ，重新打开连接时自动加载；
2 、支持保存 SQL 脚本，然后自动显示在文件列表种，双击即可打开；
3 、支持保存为代码块，可以直接在只能提示中使用，也可以拖放使用；
https://github.com/taozuhong/kangaroo

[ccw4wcc]

@lyxxxh2 #29 如果是紧急修复线上的一个数据呢，还能用代码来修复吗？执行 sql 不得比执行代码响应来的速度吗？
sql 关联指的是，你需要写一大堆 select join 才能关联到你需要修复的那一行数据，等你写完代码来修复数据，用户早就投诉疯了，你如果处理过线上紧急的修复数据，就不会说用代码来修复这种话了

[ccw4wcc]

@lyxxxh2 #29 功能肯定要用 orm 或者 sql 来写，但是紧急查询/修复线上数据，可没有时间让你去写代码来修复，都是一条 sql 丢给运维紧急执行一下

[ccw4wcc]

@haython #26 我也感觉出来应该是没有在线上导出/修复过数据的样子

[phf0313]

navicat 保存查询

[WIN2333]

@lyxxxh2 你这个 orm 写的，我看的就挺灾难的😂

[z1829909]

@lyxxxh2 你图片里的 orm 代码, 复杂度还没特别高, 我看着已经有点恐惧了哈哈哈.

[lyxxxh2]

@ccw4wcc
你说的需要复杂的 sql 且紧急的,我没遇到过。
我大部分数据库错误都是某字段类型搞错了。

但是我深刻体会修数据比修 bug 还麻烦。
我本地确定代码没问题了,才敢线上执行。
宁可他们等,我也不想有可能产生数据问题。
当然我公司体量小,没几个客户。

[lyxxxh2]

@WIN2333

有没有可能,sql 会更加灾难。
拿嵌套子查询来说 select x from (select ... fomr select ( select... ) where (xx = xx or xxx = xx ..) )

[xiaozirun]

@andytao #31 是不是发错连接了 是这个 https://github.com/dbkangaroo/kangaroo?tab=readme-ov-file