未分類
14 5 月 2020

业务开发中要求灵活性，在必要的时候直接操作数据库是否合理？

业务开发中要求灵活性，在必要的时候直接操作数据库是否合理？

資深大佬 : IssacTomatoTan 7

前提：

一个开发需求，发起一个项目，此项目会经过四个步骤后结束。 当前业务方要求，因特殊情况可以省略某些步骤直接通过结束。

开发的解决方案 1： 在对应发起流程时，加入一个可供选择的跳过步骤， 才发起任务，使用接口实现。

业务的解决方案 2： 正常发起流程，直接在数据库插入或者修改成最终结束结果。

请问： 业务的解决方案是否有什么特殊的好处或者？？ 请表达你的观点，我真不明白，望指正，谢谢。

大佬有話說 (13)

  • 資深大佬 : whypool

    直接改数据库也没啥毛病

  • 資深大佬 : pushback

    多步骤建议给内部留接口，如果只是单步骤可以直接上手

  • 資深大佬 : AngryMagikarp

    再灵活也应该有边界，不然就容易出乱子。

  • 資深大佬 : visonme

    既然要灵活性：
    1. 保持原有的设计，将该项目的几个步骤作为动态配置项，流程怎么走由也业务方自己配置
    2. 特殊需求情况下，可以再发起项目时候给出一个两个选项：按配置的业务方自己配置的业务流程走或者直接跳过所有步骤（大概就是你所提到的直接数据库操作了吧）

  • 資深大佬 : james122333

    好处就是你不用做那么多 (滑稽)
    难以回答的问题 取决于现有架构以及业务流程

  • 資深大佬 : coolmenu

    直接操作数据库的坏处是 1 没有操作日志，监控不太方便，你得写点 procedure 封装一下操作，记录日志便于审查问题
    2 等业务复杂了，这块迟早是个问题。算是业务漏洞。

  • 資深大佬 : DelayNoMay

    navicat 直接操作数据库？

  • 主 資深大佬 : IssacTomatoTan

    @whypool @pushback @AngryMagikarp @james122333

    其实主要还是在于想了解背后的动机的

    @visonme @coolmenu

    估计是业务方是想要规避一切可能的记录？
    或者是对这个操作的权限完全收紧，只能当突发事故响应处理。

    @DelayNoMay 据我所知，估计就是 mongo db.xxx.updateOne

  • 資深大佬 : pmispig

    程序员说，这个功能在界面做不出来，所以直接执行 SQL

  • 資深大佬 : stevenkang

    两套流程，一套标准流程做项目的 4 个步骤流程。另外一套流程做成可自定义的，这样以后无论是发起一个项目，还是其他啥流程，只要不符合标准流程的，都走自定义流程。

  • 資深大佬 : james122333

    @IssacTomatoTan

    背后动机看你有没有意识到搂

  • 主 資深大佬 : IssacTomatoTan

    @stevenkang @james122333 好的谢谢 这些动机的事情我在研究研究

  • 資深大佬 : jake361

    边界很重要，所以做个操作后台界面吧