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

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

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

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

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

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

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

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

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

    开了订阅号，看到序言的PV数往上跳过了自己的期望值，尤其看到订阅者中男女比例已经达到二比一时，小小的脸红之余有了一点小小的膨胀。SO笔耕不能停！虚心接受大家意见，调整了下段落布局，希望大家喜欢。

    这次，我们来简单说说关系型数据库，我喜欢使用大量的引用和比喻来阐述观点，文章会很碎同时也会比较发散，希望能为以后和之前的文章承上启下。最后我也深信一点，能够百度到的“知识”不是“知识"，所以我不是百度的搬运工。

    写SQL肯定是一种编程，准确的说是DSL（领域特定语言）编程，ruby之父松本行弘在《代码的未来》一书中用了大量的文字描述这个话题，非常引起我的共鸣，因为我常反思未来是否在业务描述中会有一种DSL可以描述特定业务，那会有多动态，有多抽象，或者这是唯一正确的道路？我想在本文埋下一个伏笔，让大家牵挂着这个问题！这里我最想说的是，主流IT媒体有这样一种观点，“21世纪人人都要学会编程”，我很赞同，但我要补充的说，“21世纪人人都要学会领域特定语言编程”，而不是人人都在写JAVA。

    关系型数据库RDBMS的使用往往陷入“误区”，我仔细分析了下，最大的误区在于场景选择！！你需要的是OLTP还是OLAP，这个误区在当下弥漫，99%的中国互联网企业做的架构有问题，那原因是什么呢？

    首先我们说说OLTP，就是传统的联机事务，你可以理解为存放线上订单的数据，后台编辑的酒店宴会厅关系数据等。OLAP则指的是联机分析，可能基于某些维度绘制出各种变化的表报，例如：酒店销售周汇总，BD人员出勤季报等。而最最要命的是往往这里的OLAP指的是ROLAP也就是带关系联机分析，所以头痛的是，程序员接到需求就一股脑儿的把这些AP的需求放到了生产环境中的TP服务器里。

    这时候一股脑儿的“优化技术”就来了，什么主从分离，方便从库出报表不拖慢主库之类文章百度一搜一大把，试问一下，一个slave能满足报表需求么？生产环境的数据库里的TP表真的能满足你么？外部的三方数据怎么办？SEM的数据难道也扔到宝贵的生产环境里去？你开始有点茅塞顿开，这根本是两种技能栈呀，分属两个部门！TP就应该放在MySQL这样的通常意义上的关系型数据库里，程序员DBA管，而OLTP是应该放在ETL（数据仓库）里由数据仓库管理员处理，你要用SQLServer或者MySQL做数据变形，简直要命！ETL的一些问题，我们将在以后大数据的文章中详细描述。

    那么问题的根本原因是什么呢？第一，需求方只知道需求，大部分产品经理无法区分这样的需求到底是由哪个部门完成，第二，有些公司根本没有数据仓库，这就有点无奈，第三，厂商的胡乱宣传让大家总期待在某一个版本会有一个allinone的东西出现！

    我的建议是，如果是报表类需求请交给ETL来处理，程序员可能只参与到ETL分层中的ODL（原始数据层）那层，区分是否是报表有一个原则很简单，需求中的报表肯定不是实时的！如果实时的报表，那么我认为他其实不是报表，已经是业务的一部分！是一种聚合后的决策用工具，如果这样的需求，必须在你的关系库里完成，当然额外的我想提醒你，如果在这样的查询中出现了select嵌套或者group having之类的聚合后筛选，我可以基本断定你的代码有问题，你缺少一张真正的物化表！不是物化视图，是一张真的表！

    如果你对ETL还有关系型数据库持续感兴趣请关注本公众号budaoxing，因为我接下来就是介绍关系型数据库的第二大误区。