仅一题,看出你对 SQL 编程的领悟力

更新时间:2019-05-20 10:25:16点击次数:451次
小 C 被安排了一次报表开发任务。
在数据仓库项目做了 2 年多的 ETL,小 C 开始对拆字段、并字段、取整、取模产生了厌倦。两年前吵着要做 ETL ,主动拿活干加班,一腔热血,到现在 5:30 就开始茫然等下班,低落的情绪还是明显被我感觉到了。
最近报表的事情特多,所以多给了一张,让她锻炼锻炼。
果不其然,小 C 又重燃了热情。在 BA 面前晃来晃去就为了那点需求要整明白。要说从 ETL 转到报表开发,有多么难度高,我看是未必的。但报表的难点之一就在于需求沟通到位。否则,像绣女一样织了很长时间的布一样,从头返工是谁都不想的。
这一点,我跟她交代的很清楚了。
//SQL 的核心//
在 BA 面前晃了两天,大概她已经搞懂需求了。
本想着顶多再有个 1,2 天就能把报表做得七七八八了。过得越久,我看小 C 的眉头皱的越紧。小姑娘要是多了几道皱纹,可不好。

“C,还顺利吗,第一次做报表慢慢来,别急”
“sp 是写好了,但报表老是慢,不稳。”
“sp 慢还是 Crystal Report 渲染得慢?”
“sp 出数据大概在 5-6 秒”
“能找到哪里慢么?”
“生成 50 年的日期数据有些慢”
凑近一看,天哪,她居然是这么写的:
//如何秒出//
SQL 编程就要有 SQL 的方言
小 C 的这种做法完全受制于过程化编程思想的禁锢,而摒弃了对数据库体系的理解,完全丢失了 SQL 应有的威力。

本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责,本站只提供参考并不构成任何投资及应用建议。本站是一个个人学习交流的平台,网站上部分文章为转载,并不用于任何商业目的,我们已经尽可能的对作者和来源进行了通告,但是能力有限或疏忽,造成漏登,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息