关系型数据库使用中的误区系列：数据的价值

    数据库这东西说起来真是一发不可收拾，其实本来只想写一篇文章总结，未曾想到写完第一节就超长了，也好，直接上一个系列吧！

    正如前文所说ANSI SQL真是一种功能性极强的DSL，如同打架必备的折椅，睡觉需要的床，踢球要的足球一样，我认为他是当下最适合通过描述过程筛选数据的语言，但注意我说的是过程！例如：我要筛选库存红色的苹果，筛选价格从高到低的订单且只要100条，诸如此类。

    但我们也常在反思对于过程的精确描述究竟是为了什么？这个查询的背后初衷是什么？我的观点是，我们描述了那么多的过程不就是为了得到预期的结果吗？我们为什么不能直接描述结果，让把其他的事情交给计算机来做呢？

   每个小伙子在追GF的过程中包含了吃饭，看电影，打LOL等等过程，所有的这些，都是为了让对方成为你的女朋友这一结果，而且常常为了达到结果你会动态调整你的过程，痛并快乐着。万幸的是，在计算机的世界里不用大费周章，你没有痛，只要你能将结果准确的描述出来，那么程序便会为你实现结果。

    试想一下，描述一句“我需要一个吃素菜的便宜的，而且我邀请朋友都喜欢的饭店”，计算机呈现的结果便会是你需要的那样，那岂不是更好。真心希望各位读者读到此处，从DSL角度，过程描述和结果描述角度，能带来你一点对于编程思想的畅想，我们频繁的使用SQL编程到底是为了什么？有没有可以让计算机学习之后，告诉我结果的技术呢？请带着想法关注本系列，关注budaoxing这个订阅号。

    《关系型数据库使用中的误区系列：最大误区》中我想表达的是在于后台业务代码和ETL之间的分层没做好，简单来说就是业务和报表分离。说到报表，最大的误区在于数据的价值！大部分的报表到底是为了什么制作出来的呢？吾以为，报表只是工具，帮助实施业务策略，提高单项指标以及整体指标。于是乎，对于报表的处理根本不在于你是否能写出这样的查询，几百行的SQL根本不是什么麻烦事，而在于和需求方沟通之后找到对方需要的关键性维度以及基于这些维度的预警和预警后所采取的策略。
   
    例如：CEO可能需要一张客服销售业绩报表，我相信只要有条件描述，SQL总能写出来，但是若能增进一步，你会否思考为什么总是这个SALES排名前列，她有什么独特的技巧和方法可以帮助提升整个团队的业务能力？又有时候需要SEM的相关报表，这些投放报表的意义是什么呢？我想不外乎是降低营销成本吧，那么怎么降低呢？光从API取得的数据足够么？是不是要结合内部的数据，尝试通过组合复合维度，环比同比CPC，CPS等来发现和预警问题，通过分时数据提高系统的敏感性，及时充分的持续微调让系统策略不失真！

    你真的对数据敏感么？每一张的报表都需要花费心思的精心设计，让数据的价值发挥出来，而不是告诉你做就做，它应该是值得你骄傲的作品！中途安利一下，到喜啦的BI系统中有200多张供业务部门查询的报表，运行在4个集群上百个节点上，而这些都是技术团队的工作结晶，所有的一切都是有价值的，保证领先于整个O2O行业。因为我相信，任何的决策都不应该是感性的，是应该基于数据做出理性的判断！

    突然发现，本来写的不是数据价值，老夫只能含泪改副标题了，请原谅我的啰嗦。本篇可能和关系型数据库关系不大，但是我还是放在了这个系列中，因为数据本质都一样，在这个数据库系列中，要多谈谈自己的想法和实践经验。

    最后，程序员在施展的过程中请不要以完成需求而做出一个个慢一拍的东西出来。全栈全业务，思考业务本身，相信自己的能力！在数据的海洋中遨游，终结所有问题！请持续关注本订阅号budaoxing，请帮忙顺手转发！马上回来关系型数据库哦！