首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  程序员

一种只写 SQL、做配置完成复杂业务系统开发的方法

  •  2
     
  •   enhancer · 27 天前 · 3332 次点击

    一看这标题,你肯定会认为基本不可能,或者认为,不写代码最多只能做一些简单业务场景实现。

    常规企业及应用开发基本过程

    为了达成我们的目标,先来看看常规企业级应用开发的基本过程:

    • 第一步,数据库建表建字段。
    • 第二步,在应用代码里创建跟表对应的业务对象,并实现及涉及到对象之间关系的操作方法。
    • 第三步,UI 层调用业务对象获取数据做渲染,或者通过业务对象做持久化操作。

    受常规开发思维惯性,我们会理所当然地认为,要完成第二步、第三步,不写业务代码,而只写 SQL,做配置,就完成各种五花八门的业务逻辑,几乎是不可能。

    回归业务系统开发本质

    让我们需要回归一个业务系统的本质,来看看第二步和第三步到底做了什么。我们想象这样一种理想情况:如果终端用户自己就是 SQL 高手,那么他应该是完全有可能仅仅通过一个 SQL 客户端完成所有业务逻辑的。实际上,40 多年前,关系数据库的相关论文,就已经论证了基于关系运算理论来表达客观世界的完备性,所以上面的理想情况才变得那么合情合理。 那么我们不禁要问,在数据库上层开发出来的业务系统,究竟是要解决什么核心问题?

    前面已陈述,关系运算理论及 SQL(已经非常接近自然语言) 以其本身的完备性,已经可以处理各种复杂的业务逻辑。那么显然,我们在上层创建的应用,显然不是为了解决数据库自身实现不了的业务逻辑,而额外做的代码工作,而是为了给不懂 SQL 的人提供的一个外壳,让他们基于这个相对固定交互的 UI 外壳,通过一些简单的操作比如点击鼠标,就能方便而并正确地完成一些背后的 SQL 操作。

    [图一 单系统数据流] image

    关系建模和面向对象的世界观冲突

    为了实现上述固定交互的 UI 外壳,我们不得不在应用层,采用面向对象的方法去串接逻辑,此时又不得不做一些对象和实体关系映射(ORM)的工作。这也是关系建模体系和面向对象思维天生的冲突所在:前者是经过严格的数学和形式化推导论证过的完备建模体系,后者是编程开发模式上的一种最佳实践。虽然有一些优秀的 ORM 框架如 hibernate 和 mybatis 来解决这类问题,但不要忘记,我们完成业务逻辑的核心就在于 SQL 的执行。而为了达成这一目标,ORM 的做法似乎有些舍近求远。那么,能不能去掉第二步和第三步,只写 SQL 做配置就能完成系统开发呢?

    解决之道

    考察常规开发的第三步工作,会发现最终产出物实际上就是让用户在 UI 上操作完成背后对应的数据库的 IO 操作,所以我们可以从输入输出这两方面发掘本质需求:

    • 一方面( OUTPUT ),由于关系数据库基于表、字段的结构化表示,一条 SELECT 语句执行的结果是可以在没有中间代码加工的情况下直接在页面上呈现的。只要 UI 层的各个组件比如列表、表格、卡片支持对相关数据的渲染呈现即可。
    • 另一方面( INPUT ),用户做的相关持久化操作,此过程比较程式化,即从页面上取得各种各样的数据,汇总到后台执行 UPDATE、INSERT、DELETE 等一条或者多条 SQL(含事务) 操作,当然中间可能有一些 IF ELSE 的处理细节。

    于是,为了达成本文的开题目标,我们做了Enhancer 云开发工作台,它是一个专门用于企业级信息系统开发的一站式工作台,用户可以基于此工作台,基本只需要写 SQL 做配置,就能快速完成全部开发工作,并且获得可以私有部署的系统。这个工作台,作为具备完整开发功能的云 IDE,还主要做了以下两方面的工作来达成只写 SQL 做配置就能完成开发的目标:

    • 一方面,它构建了一个标准化 UI 组件库(支持三方扩展),让组件的使用过程以配置化的形式呈现给开发者,直接对接 SQL 做数据组织或呈现。
    • 另一方面,提供一套完备的变量数据体系和程式化的事件动作响应机制,让开发者根据这种程式化的模式,快速地完成各种复杂的业务数据持久化操作。

    [图二 Enhancer 所见即所得开发示意] image

    使用效果

    经过实战检验,这种开发模式,比常规开发模式快至少 10 倍,并且迭代及维护成本都大大降低。目前已有上万名开发者使用该平台,完成了涵盖各个行业各种复杂信息管理应用场景的系统,见**案例。与其他低代码(low-code)开发工具只能开发简单的业务系统不同,Enhancer 基于Z-Model 理论在开发模型上的完备性,支持全业务场景开发,没有任何技术限制,欢迎尝试并指教**。

    66 回复  |  直到 2019-05-21 14:43:27 +08:00
        1
    pzyzp   27 天前
    这种系统后期维护,或者是需求变更。想死的心都有了
        2
    enhancer   27 天前 via iPhone
    @pzyzp 恰恰相反,enhancer 平台覆盖全部生命开发周期,以高效快速迭代应付需求变更著称,极大降低运行和维护成本,并为有非常强的扩展性,不只是解决 IO 无编码这么简单。详情见我们的案例
        3
    huzi67   27 天前   ♥ 3
    数据量上去了,性能调优怎么解决?
    数据库崩了,比如某一个表页崩了,整个系统就彻底崩了?

    访问量大了,如果大量使用存储过程,并发大了,因为数据库严格的事务完整性肯定会拖累系统的,到时候根本没法调。
    你们这是直接否定了上世纪 90 年代至今的趋势,就像现在不发展导弹,直接去设计滑膛炮,以现有的技术重新设计制造和推广滑膛炮肯定是以前不能比的,但是能吗?

    数据库还是单纯的持久化数据就好,简单的 select 简单的 insert 简单的 update

    我觉得在这里回复你 是浪费时间

    想当年做对日的时候 见过几千行的 sql 代码,当时都快疯了
        4
    opengps   27 天前 via Android
    仅仅适用于小用户量小数据量
        5
    charlie21   27 天前
    “额外做的代码工作,而是为了给不懂 SQL 的人提供的一个外壳”
    不错
        6
    enhancer   27 天前 via iPhone
    @huzi67 性能调优的事情都在数据库本身完成,业务层配合改写 sql 即可,我们有很多对性能,和数据量有极高要求的案例,欢迎指教
        7
    mocyx   27 天前
    SQL 的可维护性和通用语言不能比

    我看了下示例,你们这不还是 SQL+NodeJs 么,并不是只有 SQL
        8
    jorneyr   27 天前
    没有缓存,没有 MQ,没有集群,没有微服务,用户多了、高并发的时候不知道会怎么样。
        9
    enhancer   27 天前 via iPhone
    @jorneyr 不适合做互联网应用场景的应用。我们解决问题的域在企业级应用。至于集群,是可以做的,不论是数据库的分库分表还是应用层的 id 分片。
        10
    enhancer   27 天前 via iPhone
    @mocyx 目前是 90%sql+10%js 并且 js 是起脚本或者胶水的作用,不负责主程编写。如果对交互效果没有特别的定制要求,可以做到零编码:)
        11
    marsgt   27 天前
    直接用 SQL 都不做封装嘛。。那我觉得还是 GatsbyJS 更优雅一点😬
        12
    Takamine   27 天前
    你搞一套就把业务纯写存储过程的 C/S 系统出来,你看看谁来给你接手。
    真的是巨坑天坑,超级无敌坑阿。
        13
    l00t   27 天前   ♥ 1
    有种开历史倒(CNM 的 SB 敏感词过滤)车的感觉……

    不过你这个相对于存储过程直接在数据库里写代码,其实还是把 SQL 代码写在中间层的吧?这样倒是方便水平扩展了,也算是解决了传统存储过程的一大痛点。
        14
    micean   27 天前
    唯一的问题在于:
    用的人少 + 学习成本高 = 用的人更少

    流程图看起来很乱,既然是 js 的话,我觉得可以直接用 js 代替吧,暴露指定的 API 就行了
    另外企业级应用也不全是 crud ……
        15
    saulshao   27 天前
    公司内部有一个类似的东西,确实可以用,也确实可以提高开发速度。
    但是一旦遇到性能问题,或者非业务代码导致的 BUG,大家就开始互相扯皮。然后就想办法绕过。最后的结果就是大多数代码都要重写......
        16
    johnnie502   27 天前
    每个月都能看到这个民科项目在打广告,我也是服的
        17
    azh7138m   27 天前 via Android
    我记得正方也是,web 只展示,逻辑放 SQL,全是存储过程。
    维护几百上千行的 SQL 有意思吗。。。
    brainfuck 也图灵完备啊,你见过大型应用用 brainfuck 写的吗。。。
    数据量小随便玩啊,你看正方算个什么东西离线跑好久,改个东西打开一个几千行的存储过程,这还怎么操作。。。
    现在骗钱不按基本法来了吗?
        18
    janxin   26 天前 via iPhone
    这个看了一下介绍感觉就是…大概只适合于传统内部软件开发…
        19
    ditie   26 天前
    @huzi67 这个比喻好,我接下去。如果用导弹和滑膛炮来比喻项目的大小或平台的适用范围,那么我感觉 [导弹] 适用于战役场景,或者说属于面向社会大众的淘宝、微博等大企业大网站的选择;而 [滑膛炮] 则能够适应从新兵训练到小规模战斗场景,对应到现实就是中小企业的内部管理系统、ERP 系统等等。
    如此一来,导弹是那些 20%(我瞎估计的数,作为新手不知道行业体量的实际分布,简单粗暴的二八法则分一下)的尖端企业所选择的利器,滑膛炮反而是多数企业的经济选择。
    再者, [以现有的技术重新设计制造和推广滑膛炮肯定是以前不能比的,但是能吗] ,又有什么不能呢?远到印刷术、近到智能手机,很多事物都是在新的时代技术背景下被“发明”了第二次。软件开发行业正在不断发展,从语言到框架、从工具到方法论,一切都受到挑战和改进,那么 sql 驱动的编程模式又怎么不能再“发明”一次呢?
        20
    ditie   26 天前
    总论:一切抛开适用场景来评价某项技术路线或某个开发工具的论调都是耍流氓。看完楼上评论,感觉一半人在客观的表达感受,一半人在居高临下的表达感受。
    我作为新手,试用了下 enhancer 平台,还是很赞的,类似于用做 PPT 的方式编程。(虽然做 PPT 和写代码都是很讨厌的事- -#)。我认为这个工具很适合新手和系统复杂度没那么高的场景,很适合想找个框架迅速实现功能、对界面美观度不挑剔的开发者。不适合什么呢?不适合那种喜欢每一块积木都是自己打磨出来的代码狂魔,不适合在高度分工化、流水线化作业场景下工作的 ITer。
    最后扯远一点,我觉得每个人心里都会有一个想要通过代码实现的事情,或集体项目,或个人作品,代码都只是通向目标或未来的梯子,并无高下之分。正如《楞严经》中所说“如人以手指月示人,彼人因指应当看月”,也祝大家可以早日“得月忘指,得意亦可离言”。
        21
    zjsxwc   26 天前 via Android
    写什么 SQL 像 SonataAdmin 这种有实体类关系,就能自动生成 crud 功能了

    https://sonata-project.org/
        22
    KuroNekoFan   26 天前 via iPhone
    strongloop ?
        23
    woahishui   26 天前 via Android
    如果有研发维护的业务人员离职,给程序带来的影响是毁灭性的。新人入职交接工作根本没法进行
        24
    woahishui   26 天前 via Android
    每个人的思维不同,通过 sql 发现逻辑错误太难了,数据库最好做简单的增删改查,逻辑放到程序中,通过面向对象的特性减少系统复杂性。你这个做个没有复杂逻辑的还行。比如给一个页面增加属性,连带着关联的 8 张表,你总不能保证人人都能记住,而且确保无误,
        25
    PANWCS   26 天前
    这种把逻辑落脚到 SQL 语句中开发方式在一些传统券商中使用得比较多。总感觉,虽然说是在技术上的倒退,但是能够满足当前小用户量的需求就有存在的意义。
        26
    sagaxu   26 天前 via Android
    传统行业 SQL 打天下很多啊,一条 SQL 打印出来好几十页
        27
    enhancer   26 天前 via iPhone
    @woahishui 恰恰相反,大家都基于 sql 和配置作为开发基础,交付工作几乎是零成本。注意,在企业级信息软件领域 写 sql 是绕不开的环节,enhancer 开发并没有额外增加新的开发知识成本。所以估计你不是这个领域的开发者。
        28
    crazypig14   26 天前
    在特定场景下用用挺好的
        29
    l00t   26 天前
    @enhancer #27 但是我作为开发者的话,我是不会愿意去使用这类东西做开发的。SQL 真的很简单,3 个月精通,技术上的成长和进步在哪里?工作全在写业务逻辑上了,脱离了这套东西自己写个简单的 GUI 都用不上工作中习得的技能,跳个槽都可能面临没有地方可去的局面。
        30
    ditie   26 天前
    @l00t 看来是个现实问题,不过我觉得要分清楚 [技术] 和 [平台] 的区别。技术是可以承载一个人的职业发展和经得起探索沉淀的,而平台是用来使用的。另外 [3 个月精通] 的说法是不是把 SQL 类的工程师说的太不值钱了吧。。。。前端是赶潮流,后端 SQL 才是越有经验越值钱呀,听说过首席架构师,没听说过首席前端师啊
        31
    enhancer   26 天前 via iPhone
    @l00t 对于个人开发者确实是这样,自我成长得更少了,但如果有一天你自己当老板,或者做腻了增删改查,希望时间自由一点寻求其他方面的提升,或者自己希望接外包干活,你肯定希望尽可能快速低成本的完成任务产生价值。就好像,给你电据来砍树,非要用斧头砍,并认为这样锻炼身体,那也未尝不可。最好从汇编语言开始编程,这样锻炼和成长可能更大。
        32
    l00t   26 天前
    @ditie #30 人的精力是有限的,一天时间就那么多。你大部分时间都在一个平台写业务逻辑的话,留给自己搞点技术的时间就少了。同样是干活,为何不找点更通用的适用面更广的活干呢对不。大家面试还都问工作经验呢,问工作中做了什么,几个人问你业余做了啥? SQL 总共就那么点东西,没什么经验可说的,需要经验的是 DBA。但是写 SQL 业务逻辑的和 DBA 明显是两个截然不同的岗位,基本搭不到一起。架构师也不是会点 SQL 就能胜任的,你至少得能自己也写一个这样的平台才有架构师的起步资格。而这个平台是 SQL 写的么?
        33
    gz911122   26 天前
    @ditie 虽然我是后端,但是你这样鄙视前端是不对的..目前就评价水平来说,java 后端这边才是不思进取的一大片.
    java 都 12 了,8 都玩不明白的还一大把呢..
    前端不管怎么说,大部分都对响应式,asm,等等之类的有个认知,身边的不少 java 都是一脸这是啥玩意的表情?.

    回归正题,前端架构师也是存在的.
        34
    gz911122   26 天前
    @ditie 再其次,sql 有啥之前的来来回回就那么些东西.你又不是数据库研发,就一个工具而已....
    现在都说单表增删改查,更用不到那些奇技淫巧了.
        35
    rizon   26 天前
    有些系统和场景用这个还是不错的。
    不过对于一些大型的企业解决方案,这个东西还是有局限性的,有些东西的逻辑是真的复杂和庞大,就算不说能否支持,这种方式在过于复杂的业务场景下维护成本就不再是降低而是非常高了。
    不过这东西确实有适合它的开发场景。
        36
    l00t   26 天前
    @enhancer #31 从接包的意义上来讲,确实是可以用这个。我的观点只是说拿这个当作正式的全职工作的话我是不会愿意的。快速开发出点活我并不介意……
        37
    smallyin   26 天前
    最近项目客户指定了采购某类型搭建平台,也是美其名曰不写代码,只写 sql+做配置,系统也只有一个数据库,加一个 war 包,用起来想死的感觉~真心不敢恭维~适合小作坊折腾折腾玩一玩,真的用来做稍大一点标准的解决方案项目,大概是要你命三千的感觉~
        38
    xFan   26 天前
    一大堆存储过程·维护起来要死···
        39
    chanchan   26 天前
    还不如代码生成呢
        40
    ditie   26 天前
    @l00t 嗯 我也刚好 30。话说我猜平台应该是 nodejs 工程师写出来的
        41
    l00t   26 天前
    @ditie #40 …… 30 那个是层号
        42
    ditie   26 天前
    @gz911122 哈哈 木有鄙视的意思哈,我一直觉得只有不会用技术的人,没有不行的技术。不过我倒一直感觉现在这种分前端后端是一种认为割裂的分法或者认知习惯,其实到了个人成长的后期应该都会要用某种形式弥合或跨过这个裂缝
        43
    ditie   26 天前
    @l00t /吐血。。。 哈哈 刚来这个论坛不久 闹个大笑话
        44
    tabris17   26 天前
    其实就是一个高级点的数据库管理器 UI
        45
    Raymon111111   26 天前
    那你猜猜为什么阿里禁止使用存储过程
        46
    razertory   26 天前
    这个可以引入 GraphQL 技术,然后用自动化的方式把数据库 schema 映射成 GraphQL schema
        47
    notreami   26 天前
    执行力很强,唯一的问题是组件难堆和维护。
    看了下前面的评论,突然觉得,挺搞笑的,吐槽也吐不到重点,反而显现眼见。
        48
    areless   26 天前
    Ruby on rails 脚手架。。。
        49
    ditie   26 天前
    @Raymon111111 可能与设计思路或行业有关吧,我知道有些银行的业务逻辑全是在存储过程,代码里不能有 SQL
        50
    woahishui   26 天前 via Android
    @enhancer 如果一个人写了一个复杂的联动 sql,交给另外一个人添加功能,怎么可能不复杂啊,解手的吐血的心都有了,而且数据库代表了对象的对应关系,并不表示操作的逻辑,这样肯定是无法做大的,碰到需求有变化,没错直接更新 sql 就可以,但是困难的是把更新的 sql 写出来。
        51
    woahishui   26 天前 via Android
    @enhancer 你是现在更新内容是简单,但是更新的 sql 写起来是要吐血的。
        52
    woahishui   26 天前 via Android
    @enhancer 我敢保证,如果有人使用项目的维护期不超过 3 年,使用的人就做不下去了,如果需求变化快可能更短时间
        53
    siteshen   26 天前
    “那么显然,我们在上层创建的应用,显然不是为了解决数据库自身实现不了的业务逻辑”,没看出来显然在哪里。数据库并不是一切,强行用数据库表示一切才是舍近求远。
        54
    woahishui   26 天前 via Android
    @enhancer 我就不说多,你们在自己的系统中实现一个完整的工作流,可以根据条件判断工作流流向,了进行流程的,放到 v2 上让我们看看。然后你让另外一个人添加工作流中每一步的权限控制写个试试,
        55
    woahishui   26 天前 via Android
    楼主这么说显然连类的基本概念都没有理解,类是变量和方法的集合,为什么会有变量就是为了保证在某个几点确保能获取到对象状态,全写 sql 面向过程开发很痛苦。我是大家最看不上的.net 程序员。
        56
    akira   26 天前
    小公司内部 用应该没太大问题
    互联网行业就算了
        57
    littlewing   26 天前
    如果你是用 oracle 的话,这样做没问题
        58
    daodao116   26 天前
    这种方式,我就没见过最后成功的。
        59
    l00t   26 天前
    @woahishui #54 难者不会会者不难。你思路就没转过来。
        60
    enhancer   26 天前 via iPhone
    @woahishui 你说的工作流,变化的角色权限,以 sql 驱动的开发方式在 enhancer 平台上都非常轻松的实现,已经经过了非常多的实战项目检验,也经得起时间检验,欢迎尝试。如果只是固有观念上的排斥,这是没有意义的,我们的社区有各种实战问题的实现和解决办法,也欢迎把问题和需求具体化,进一步讨论。
        61
    woahishui   26 天前 via Android
    这不是思路的问题,开发人员在工作有一年到两年的时候肯定都会赞同这个项目的做法,工作时间在 3 年以上的,只要用心写过的肯定不会再项目中这么做。
        62
    woahishui   26 天前 via Android
    曾经的我也是这么做过把所有逻辑放到数据库,现在统一都用的是面向对象,一般都要有工厂,策略,模板,观察者,这几种少不了,
        63
    woahishui   26 天前 via Android
    这样无论是代码的扩展行,代码的复用,以及项目的稳定性上都有个起码的保证。
        64
    loading   26 天前 via Android
    这是一个无法被接手的工具,非常适合养老型企业,只要 SQL 维护那人脑子坏了,没人能改。
    一条 SQL 几百 Kb 是常见的。当小说看都可以了。
        65
    zidian9   26 天前
    我感觉这玩意搭后台很好用,额,前台就算了,有各种异步缓存消息等等
        66
    abcbuzhiming   26 天前
    Sql 本质是一个入门简单,但是精通很难的语言,比一般的编程模型难的多,所以它才被更通用的语言在竞争中占据了上风
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   811 人在线   最高记录 5043   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 25ms · UTC 19:16 · PVG 03:16 · LAX 12:16 · JFK 15:16
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1