逻辑大量的写在 sql 语句里

2022-02-21 16:40:54 +08:00
 moxiaowei

今天看了下同事写的代码,才发现他居然喜欢把大量的逻辑写在 sql 语句里,跟他讲了下,他说是以前同事教的,我认为这样写可读性实在太差了,但是他也不愿意听我的!想听听各位大佬怎么讲。 下面是一段 sql

      SELECT
        m.id,
        m.menuname,
        m.link,
        m.parent_id,
        m.menutype,
        m.sort
--         CASE
--         WHEN pm.parent_id > 0 THEN
--         1 ELSE 0
--         END hasChildren
        FROM
        menu m
--         LEFT JOIN ( SELECT DISTINCT parent_id FROM menu ) pm ON pm.parent_id = m.id
        WHERE
        m.is_deleted = 0
        <if test="userId !=null and userId !=''">
            and m.id in (SELECT DISTINCT
            rm.menu_id
            FROM
            role2menu rm
            LEFT JOIN role r ON r.id = rm.role_id
            LEFT JOIN user2role ur ON ur.role_id = r.id
            WHERE
            rm.is_deleted = 0
            AND ur.user_id = #{userId} )
        </if>
        ORDER BY
        m.sort

这只牵扯到 3 张表,就这么多 left join ,我后面又去翻了翻 10 来次 left join 的也很多。
17202 次点击
所在节点    Java
244 条回复
liuliangyz
2022-02-21 16:42:30 +08:00
没吊事,等哪天上了 sql 筛查,这类逻辑写到 sql 当中的直接被干掉~
我觉得这类人特别二
x86
2022-02-21 16:48:05 +08:00
别管,听你的去改万一出啥问题,你也要分个锅
efaun
2022-02-21 16:49:08 +08:00
能 run 就行
levon
2022-02-21 16:51:22 +08:00
这 sql 不算复杂,而且不算是业务
gimp
2022-02-21 16:52:05 +08:00
“这个功能明天就要”
Jihua
2022-02-21 16:53:30 +08:00
没怎么写过 SQL 的菜鸟请教一下:对于同一个业务功能,把逻辑写到 SQL 里还是写到 SQL 外运行耗时更少?
moxiaowei
2022-02-21 16:54:16 +08:00
@levon 这非要堆到 10 来个 left join 搞死 sql 才算复杂么?
est
2022-02-21 16:54:31 +08:00
这有啥不好的。sql 就是最古老的微服务,低代码啊。

最开始只有些教授发明了 B 树;

后来有穷 B 研究生把改成一个库可以被 C 语言调用

后来就有聪明商家包装成了一个 tcp 库拿出去卖钱

其次,后装市场为了迎合臭不要脸不懂技术分析师的需求,发明了 sql

没想到就火了。于是商家就把加上存储过程就是 RPC ,而且是 serverless 的小代码哦。insert/update/select/delete 对应 RESTful 的 CRUD ,sql 其实就是 GraphQL ,认证权限功能,分裤分婊功能,齐活了。
test3207
2022-02-21 16:54:33 +08:00
逻辑全写在代码里,都上事务吗?
多次 query 的额外网络和 IO 开销需要考虑吗?
有没有好哥哥讲一讲
felixcode
2022-02-21 16:56:06 +08:00
这样写可能不方便其它人维护,但用 join 的方式先做筛选再给程序的确是运算开销最小的。
nitmali
2022-02-21 16:58:35 +08:00
有一瞬间我以为我在看我们公司的代码 [doge]
woodensail
2022-02-21 17:00:25 +08:00
@Jihua 大多数情况下,还是数据库里更快一些,但是问题在于,应用服务器可以轻松的平行扩展,数据库可就难了。
所以一般是数据库先简单筛下,然后交给应用服务器做后续处理。
cando
2022-02-21 17:04:23 +08:00
挺正常的 习惯就好了
有时候复杂需求就需要这种
注意项目统一使用、语句优化好执行速度合理、写点注释
murmur
2022-02-21 17:05:30 +08:00
正常,我也听过这样的逻辑,sql 写业务,直接热发布不需要重启 tomcat
kiracyan
2022-02-21 17:07:10 +08:00
工业和老的系统很多逻辑都写在数据库存储过程 虽然可读性很差 但是是一种很廉价的 RPC 和热更新方案
SuperXRay
2022-02-21 17:09:12 +08:00
逻辑写在 sql 语句里有啥问题???
写一大坨业务代码就不恶心吗?就可读性好了吗?
yazinnnn
2022-02-21 17:09:39 +08:00
以后业务量大了,俩表跑到不同的数据库上了咋整?
chenmobuys
2022-02-21 17:11:08 +08:00
这也算正常 SQL 吧,楼主还是没看到复杂的 SQL
Chad0000
2022-02-21 17:14:36 +08:00
只要给够钱就不是问题。我现在就涉及到这样的屎山代码,幸运的是我在海外,慢慢来,改好了反而是贡献的机会。
yor1g
2022-02-21 17:18:31 +08:00
又不是存储过程 一个小查询没啥问题 不能 join?不能子查询? 不如写下你的做法给大家看看

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/835439

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX