分类
大杂烩

关系型数据库使用中的误区系列:最大误区

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

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注