一文搞懂SQL：业务实践篇
极客时间编辑部
讲述：初明明大小：4.67M时长：05:06
你好，欢迎收听极客视点。
SQL 即结构化查询语言，顾名思义，它的基础在于结构化的数据库表，最主要的应用场景在于数据查询。虽然 SQL 也可以像其它语言一样有一些高级的写法，但它的主战场并不在此，仍要回归到对数据库表的操作和处理中。最近，腾讯 CDG 数据分析师李扬洁在公众号“腾讯大讲堂” 发文，总结了日常工作中常用的 SQL 业务实践，供你参考。
如何尽量地少给未来挖坑
首先，不要起一些奇奇怪怪的名字。SQL 里的数据库表，就像是其它语言里的对象，往往是数量极大的。而且随着时间的推进和业务的发展，基数会持续放大。所以对于数据库名、数据表名、字段名，尤其是一些主键、索引的命名，务必要有一套相对统一的规范。
然后，不要并行维护多个版本的数据。因为业务的拓展，数据背后的口径可能有所变更，基于旧有的数据报表，简单修改后出一份新数据，是一种成本较低的实现方式。但最好不要并行维护多个版本的数据，当版本超过 3 个时，维护成本是直线拉升的。所以做数据变更时，一方面可以降低变更的频率，另一方面尽量在原有报表里修改，并替换掉原有口径。
其次，不要在单个脚本里写过多内容。统计逻辑的实现，就像是传统工业里的不同工序，这个过程存在两种极端。一种是把一个逻辑在横向 / 纵向细分为太多的工序，部署过多计算任务，形成很大冗余；另一种是完全打包在一个大脚本里，这种情况也不利于问题定位和中间数据处理。所以不要在单个脚本里写过多内容，可以将它拆分进最优数量的计算任务中。
再次，要有一些基本的约束条件。做一些事情时，不仅要立足于眼下的问题，也要考虑未来可能发生的变化。很多数据异常都发生在业务变化时，旧有的逻辑不能适应当前的场景。所以在写脚本时，要考虑未来的场景，有一些基本的约束条件，这样会让所部署的任务有较好的稳定性。
最后，要采用尽量简洁的写法。能够一步到位的统计逻辑，就采用尽量简洁的写法，千万不要绕圈子。尤其是一些核心脚本，是要在不同环节、不同阶段的同事之间传承的，很多人并不了解当时的业务背景和需求逻辑，如果写法太绕圈子，最终就把大家一起绕进去了。
如何健康地做数据规划
数据规划是一个层级比较中等的概念，往下一层，做需求开发，往往只聚焦于特定的需求点，并不涉及其它内容；往上一层，做数据工程，又是基于整个部门、整个产品形态的框架搭建。但数据规划更多是应对一个相对独立的业务场景所做的规划与设计。
一个不够好的数据规划，可能会引发后续的诸多问题，比如原始信息的保留、技术实现的最优路径，以及计算任务的细分问题等。另外，在不同的业务场景下，可以有不同的数据规划思路。粗糙地讲，可以分为数据基础层和业务细分层独立处理。
数据基础层：做一个数据规划，首先应该要考虑数据本身，在数据基础层里，应暂时抛开具体的业务细节，以数据为重。这时应在处理中尽量保留原始信息，同时要对数据源做好质量检验。原始信息要完整，数据质量要合格，任务部署要轻便，这些是数据基础层的一些目标，也是后续工作的一个前提。
业务细分层：数据基础要独立而完整，面向数据本身；业务细分层则可以去细分实现，面向业务细节。基于不同的业务目标，可以从源表中筛选不同的内容，用于应对特定的场景。这样的数据 + 业务层级，形成了一种“总 - 分”结构，是数据规划的其中一种实现方式。
如何在破旧与立新之间寻找平衡点
很多工作都是基于当前场景，即使做了详尽的规划和思考，也不可能应对未来的所有问题。当业务逐渐深入发展时，很多内容也需要做一些同步处理，小的层面是一些数据表和视图的变更，大的层面可能涉及计算平台的迁移、视图系统的重建等。
破旧与立新，往往是一个长期存在的问题点。不需要每天都进行自我“革命”，但改良和优化，则是一个长期过程。在这个长期过程里，我们需要在破旧与立新之间寻找到平衡点。
以上就是今天的内容，你也可以通过清华大学计算机博士陈旸的极客时间专栏《SQL 必知必会》，了解 SQL 从入门到数据实战的一系列知识。以下是这门课程的目录，供你参考。使用极客视点专属口令，还可以享受立减优惠。
优惠口令：studySQL6
适用专栏：《SQL 必知必会》
适用规则：立减 10 元（满 40 元可用）
有效期：7 月 17 日 - 7 月 23 日
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论