逻辑大量的写在 sql 语句里

[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 的也很多。

[dqzcwxb]

@moxiaowei 喜欢把逻辑写数据库的人其实是 DBA 而不是码农

[wolfie]

一点问题没有，就俩 left join 还是在子查询里。

一边觉得同事菜，同事应该听我的。

发到 v2 发现自己菜，v2 所有人应该听我的。

[quan01994]

见过更复杂的 。 最后的意见别改。

[tabris17]

谁写的谁改，你比他早跑路就行了

[liprais]

哈哈楼主这喷的两个 left join 里面只有一个是真 left join .....

[InvincibleDream]

假如你和同事都会 java 和 c ，而且项目里同时用两种语言。你会和同事讲 C 的代码可读性太差，不要再写了吗？

[oneisall8955]

代码和人，一个能跑就行

[aecra]

@james2013 我们数据库老师做的项目就这样，一条 SQL 语句占好几屏，还说这是标准，都看吐了

[yeyang5211]

这种简单的 join 写在代码里和 sql 里可读性都不差,
join 十几张表的逻辑拆成代码也不好看 可读性照样差,你看他查了十几次数据库, 筛选了一堆数据
经常读着读着不知道原来的目的了.
一般遇到这种我的倾向是拆成 3 个左右小一点的 sql, 代码清晰了, sql 也好读了. 别人写的屎山就当没看到了 , 改这种东西折寿.

[golangLover]

可读性是一件事，debug 困难是更大的问题。我会要求他重写

[deplivesb]

这个 SQL 很复杂么？一个 leftjoin 就是个复杂的业务了？那你是没见过我司长达几百行的基础业务 SQL ，已经运行了好几年了，很稳定，可比你所谓的“把业务写在代码里”可读性强多了，维护起来也比又臭又长的代码方便。即使业务变更，前后对比 SQL 不比翻代码清晰？？ OP 还在#34 楼喷别人干不过三年，我看你把复杂业务写成代码的你能干多少年。

[ikas]

看起来是权限表,除非你们用户非常的多..否则权限相关这点数据量 2 次 left join 没啥问题



当然..我看了下我们的代码是这样的....


select id,name,type
from sys_resource
where exists(
select 1
from sys_role_resource
where sys_resource.id = sys_role_resource.resource_id
and exists(
select sys_role.id
from sys_role
where sys_role_resource.role_id = sys_role.id
and sys_role.id in (
select sys_user_role.id from sys_user_role where sys_user_role.user_id = :userId
)
)
)

[hidemyself]

单单就这个 SQL 而言，不复杂，而且也没什么逻辑。
那种 ERP 和 OA 的项目里的 SQL ，才叫复杂

[potatowish]

SQL 语句尽可能不要包含太多逻辑，数据层就干数据层的事，逻辑应该放在应用层，包含大量逻辑的 SQL 短期看省事，长期非常难以维护，慢慢就成了没人敢动的屎山。

楼上不少人说什么不够复杂的，显然是偏题

[efaun]

lz 是真的菜, 而且还是不接受意见的菜 🤧 自己在小公司干了几个月, 见到没学过的东西就说不合理, 咋滴, 公司是你开的? 在 v2 找不到同水平的菜鸡(好像找到了一个?)认可就破防了, 咋滴, v2 是你建的?

[fanchenio]

我个人觉着楼主发的例子还算可以，没有多复杂或者大量逻辑，如果楼主觉着复杂或者逻辑繁杂的话，求贴出来一个解决方案，就按照你发的例子，如果你写代码要怎么写，虚心求教，想看一下。

[guaguaguaxia1]

反对楼主的都是真心的？ SQL 语句里写逻辑看你后面怎么维护，屎山都是不经意间堆起来的，等你发现兜不住了再转身，屎山已经把你淹没

[l00t]

菜狗。这种程度的都觉得可读性差，是你的问题。

[l00t]

@guaguaguaxia1 写代码里怎么维护？ SQL 代码也是代码，你能写在 Java 里维护，同样的逻辑写在 SQL 里就不会了么？

[adoal]

@moxiaowei 阿里那个什么 Java 规范里说连 JOIN 不得超过几个，是因为他们当时用的 MySQL ，对复杂 SQL 支持很差，多表连 JOIN 真的会搞死…但世间又不是只有 MySQL 这种残废。不说可读性、可维护性，只说性能，多表连 JOIN 根本不是 evil 。