关系型数据库使用中的误区系列:业务字段展示字段傻傻分不清楚

    松本行弘在《代码的未来》中领悟道,这世界上没有java编程,没有ruby编程,更没有php编程,其实这世界上只有编程这两个字呀!

    好喜欢这句话,我觉得数据库编程也是一样的道理,虽然我们在谈数据库,更多的探讨是如何拥有编程的思维去处理这些问题。当碰到跨语言,跨平台的编程时,我们会称之为架构,但其实本质还不是在编程么?最后你会看到,人的架构永远大于软件架构,编程技巧只是人类处理真实世界问题在代码中的体现!这是我的感悟。

    作为系列的第三篇,我们谈谈关系型数据库常见的问题,也是初创型公司不能高速发展乃至转型的羁绊,业务字段展示字段傻傻分不清楚!

    先从一个简单的例子开始说起,我们总会设计各种各样的管理系统,例如酒店管理系统,里面管理着所有的业务实体,酒店实体自然是酒店业务在代码中的映射。我们常常会接到一个类似的需求,需要为菜单中包含宫保鸡丁的酒店标识为上海味道,前台可以基于这个标识筛选出符合期望的酒店。

    很糟糕,这是一个标准的死亡陷阱,程序员先做了第一件事情,为酒店增加了一个属性叫做上海味道,对应的关系表也多一个字段。第二件事,必然的会修改所有可以触发该字段变更的地方加入新逻辑,若这是一个复杂的系统,必然痛苦不已。
    
    所有初创公司的研发团队都消耗在了一些无用的事情之上,很快产生边际效应,他们已经无法应付真正的新品类拓展,光是打补丁便已经停不下来。那么到底是哪里错了呢?

  我要否定的就是这两件事,它们是不对的,首先第一点,我想先解释一个问题,什么是业务?我个人理解业务其实是一套流程,可以用UML工具绘制出来,业务绝对不是一套炫酷后台系统原型,更极端的说,是把真实生活中流程映射到计算机系统层面,他的每个环节对应了不同的部门,对应的产生了一系列的指标,有了指标自然也要有正确方式去使用工具驱动完成这些指标。在我的例子中,上海味道这个字段不是业务流程中驱动业务前进的字段,他的本质只是一个展示字段帮助提高用户格式化数据获得体验。

    这就牵出来第二个问题,业务字段和展示字段是同一个东西?他们都存放在关系型数据库中么?我的回答是否,初创型公司给C端用户体验的网站以及客户端往往都会从直接从数据库中读取数据,虽然很多公司表面上做成了微服务(多端发展导致不得不实施的结果),但他的数据源还是一个问题!试问一下,我能把含有酒店总经理联系方式的酒店实体表供前台网站读取么?即使前台程序员能控制用户的展示,那么前台的程序员真的需要知道这个字段么?万一被黑客攻破了网站难道你的数据就赤裸裸的暴露出来了么?

    终于,我们发现前台展示层最需要的持久层应该是一个文档化的,全文搜索的系统,关系对他只是可选的。他只是存放了业务字段的投影,也可以基于业务字段存放一些自己的复合字段。你根本不用增加一个表字段叫上海味道,也不用在菜单编辑保存的时候更新这个字段,他只是在重建前台index的时候被更新,至于前文的第二件事情,怎么更新呢?我们需要一篇新的文章,基于项目内和项目外的实时异步通讯,在这个文章之前我们还要探讨下本地代码方法和远程RPC到底有什么不同。

    这个问题和《关系型数据库使用中的误区系列:数据的价值》中导致犯错的原因有点类似,需求方的原始需求被错误的分层,业务字段和展示字段傻傻分不清楚!该前台程序员做的事情被扔到了后台来,你甚至可以很简单的理解,后台不用排序筛选的字段都不是业务字段,但具体的应用还要看公司业务的需要!

    后记,这个原则,是在到喜啦团队中反复强调遵守的原则,他真的可以帮你避免了很多无用的工时开销,更好的理解业务!安利时间又到了,在我们首席科学家botao带领下,我们选择solr为前台千万级的PV提供个位数毫秒的数据响应能力,恩。

已发布

分类

作者: