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

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

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

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

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

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

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

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

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

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

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