开了订阅号，看到序言的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，因为我接下来就是介绍关系型数据库的第二大误区。