逻辑大量的写在 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 的也很多。

[dr1q65MfKFKHnJr6]

你如果不举例子， 我会支持你反对写大量逻辑在 sql 里。
但是你这个例子 并不复杂。。。我见过极端的 SQL ，一个 SQL ，80 多行，各种嵌套各种 in 各种 case , 一旦数据准确性有问题，看到眼睛疼

[shadowfish0]

赞同#204 ，#205

我不知道为什么这么多牛人反驳楼主的论据是：“就这点 SQL 你看不懂？”

能在工程领域说出这种话的人，水平能有多高？

为什么要有这么多设计模式，为什么要有这么多方法去规约代码书写的方式，为什么《软件工程》这门课是大学必修？

代码写出来谁不会啊...真正难的不就是如何让这么多行代码能够易读、可维护吗？数据层就干数据层的事情，业务层就干业务层的事情，这种最基本的东西都有争论的吗？

最基本的，业务逻辑要改怎么办？是 SQL 语句好改还是 JAVA 代码好改？

[adoal]

难道在某些一互大（或者精神一互大） cruders 的母校里软工是必修课而数据库只配选修

[qaweqa]

@shadowfish0 按你这种需求那不需要用关系型数据库

[felixcode]

@shadowfish0
大量关系型数据库费死劲的优化 join 等性能，各种版本迭代，各种高价卖给客户，最后到你眼里还不属于数据层的东西。

软件工程里数据库的功能难道不是以最高效的方式给其它系统提供数据增删改查吗？

拿几行 SQL 语句出来这么多人都说不难看懂，那也就不难维护，到你这就是千难万难不好改，不想学 SQL 不想学关系型数据的理由各种各样，非得把拿难学难用难维护当挡箭牌吗？

[ktqFDx9m2Bvfq3y4]

@Joker123456789 #205 我和你的观点一致，技术要不断更新跟得上时代。

而且我就是楼上个别所说的 35+程序员。

[cassyfar]

@Joker123456789

你说的特别到位

这个主题把好多人的水平都暴露无疑

[ktqFDx9m2Bvfq3y4]

@Chad0000 #226 而且我还搞得更极端，我连外键都不设置，也不在 DB 层做过多数据校验。当然 DB 能二次把关最好，但这无意中会增加 DB 的压力，于是干脆完全交给应用层好了，DB 就只做两个功能：存储和查询数据。

越简单越不容易出错，同时也越容易扩展，迁移。

[yzbythesea]

再补充下，数据库基本只能垂直扩展，即使水平扩展，收费也很贵。服务器可以很轻松的水平扩展，收费也便宜。所以基本运算压力都会放在服务器上。我从毕业到现在接触的生产服务都是用 nosql 作数据库，实际就是把运算压力减小到了极致。即使现在很多 nosql 做到了 sql 的 transcation ，我们也不敢多用，也是因为运算压力大。做好就是一个 put ，一个 get ，delete 都别，设个 TTL 就好了。

[fuchaofather]

写 sql 也挺好的

[NeoZephyr]

这不才 3 个吗

[stephanew]

@SuperXRay 那你哪来这么多戏啊，要你来揣测别人是陈述还是骂人秀优越？你在这咬文嚼字无非就是想说"我虽然同意 58 楼但那不是我说的，我只是帮你们翻译一下，所以那不是我的观点"? 这次我的理解到位了吗？

[stephanew]

@mingl0280 人家哪句话说看不懂了？自己看屎山习惯了看出优越感来了？你用的工具方法别人也一定要用一样的？几个小时对于你可能多了，几秒吧。

[SuperXRay]

@stephanew 你真是戏多

[stephanew]

@SuperXRay 还好，看不惯某些人而已

[6NCQWh99X46kZv6x]

互联网现状，眼看着从‘sql 里要不要写逻辑’ 变成 ‘这个 sql 复不复杂’

[ly1836]

@Chad0000 赞同

[moxiaowei]

@stephanew 别跟傻子计较，我都不理他们了

[mingl0280]

@yzbythesea 你这是带需求分析的，楼主是不带的，他数据库可能万年都扩不到需要增加第二台服务器的水平，这种情况考虑横向扩展就是脱了裤子放屁。

[mingl0280]

@stephanew 如果你把 SQL 都当屎山，我觉得你可能撑不到 35 岁失业。