Excel用了多年,是时候重新认识一下数据库了

前面分享了一些 SQL 脚本，和一些 DuckDB 相关的教程。

很多文章关注的是：

某个 SQL 怎么写。

某个功能怎么实现。

某个场景如何自动化。

但是一直缺少一篇文章，真正聊一聊：

为什么要使用 SQL？

为什么我一个普通牛马的日常工作，也值得使用数据库？

这篇文章不讲 SQL 语法，也不讲 DuckDB 的具体用法，只聊聊这些年自己在数据处理方式上的一些变化。

数据库并不是只有大数据才能使用

很多人对于数据库的第一印象：是Oracle、SQL Server、MySQL等

它们通常出现在：大型系统、企业平台、服务器环境。

所以很多人的认知是：

数据量很大，才需要数据库。

我的数据只有几个 Excel 文件，用 Excel 就够了。

以前这种想法没有问题。

因为传统数据库确实存在一定门槛：需要安装、需要配置、需要管理、需要导入数据。

对于企业系统来说，这些都是合理的。

但是对于个人来说，如果只是处理一些日常数据：

几个 Excel、几个 CSV、一些参数文件。

为了使用数据库搭建一整套环境，成本确实有些高，有点用高射炮打蚊子的感觉。

所以过去很多场景不是数据库不能解决，而是：

使用数据库本身的成本，超过了问题本身。

Excel没有错，只是它解决的问题不同

Excel一直是非常优秀的工具。

查看数据、数据统计、数据分析、制作报表。

这些场景，Excel非常方便。

很多Excel高手，通过复杂公式、函数、透视表，也可以完成很多工作。

但是随着工作深入，会慢慢发现一个问题：

Excel优化的是人的操作能力，而不是数据处理流程。

一次任务：可能没有问题。

但是如果变成：每天执行、每周重复、数据持续增加、多个文件关联。

人的操作就会逐渐成为瓶颈。

因为不管Excel多么熟练：打开文件、输入公式、设置格式、筛选数据、关联其他文件、检查结果。

这些步骤始终存在。

比如某一个数据统计任务：初次完整理解流程，正确输出结果，可能需要十几分钟甚至半个小时。

随着重复次数增加，越来越熟练，最终也可能需要5-10分钟完成一次操作。

最终这个时间很难继续压缩，因为最终消耗的是人的时间。

SQL改变的，是处理数据的方式

后来接触 SQL 后，最大的变化不是发现了一种更快的查询方式。

而是发现：很多重复性的工作，其实可以被描述成规则。

以前：拿到数据、打开文件、开始操作。

后来：分析数据关系、整理处理逻辑、让程序执行。

第一次写 SQL：可能需要花更多时间。

但是逻辑建立以后：下一次执行、下个月执行、换一批数据执行。

流程都可以复用。

这也是 SQL 最大的价值：不是单纯处理更多数据。

而是把一次性的人工操作，变成可以重复执行的流程。

一个实际案例：28万条5G外部邻区一致性核查

之前做过一个5G外部邻区一致性核查案例分享。

数据涉及：gNodeB信息、小区参数、跟踪区域信息、外部邻区数据共5张表。

其中一张 NR 外部邻区表，就有28万多行数据。

如果按照传统Excel方式处理：多表关联、人工匹配、筛选异常、整理修改内容。

数据量一大，操作复杂度会明显增加。

问题不是Excel做不到。

而是这种固定规则、多表关联的数据处理，更适合交给数据库完成。

后来的处理方式：先将MML报文解析并入库。

然后通过SQL完成后续关联分析。

最终：MML解析入库不到20秒、SQL核查不到1秒、输出修改命令秒级。

整个流程2分钟内完成。

这个经历让我意识到：

很多时候，提高效率不是把Excel用得更熟练。

而是换一种处理数据的方式。

参考历史文章：28万条5G外部邻区数据，如何2分钟完成一致性核查

SQLite让我发现：数据库也可以很轻量

第一次接触的数据库是Access，使用中遇到数值计算超过一定长度会报错加上性能也不大够用，放弃了。

第二次接触的数据库中oracle，装了oracle11g桌面版，安装麻烦，有时数据库装好了，但是PLSQL连接失败，各种折腾无效，无奈只能重装系统再安装，使用必须先建表，再导入数据才能使用，总之使用门槛太高。

第三次接触的是SQLite，它改变了我对于数据库的认识。

以前觉得数据库就是：服务器、账号、权限、复杂环境。

但是SQLite告诉我：数据库也可以只是一个文件、不需要搭建复杂环境、不需要维护服务。

这让我第一次意识到：数据库并不是距离普通人很远的东西。

而且SQLite一个单文件数据库，存了1-2年的指标，一个单表三千多万行了，查询统计依旧够用。

从Access到Oracle再到SQLite，慢慢意识到：数据库不一定非得是重型武器，轻但是够用就行了。

DuckDB进一步降低了SQL进入日常工作的门槛

后来接触DuckDB后，发现它更加适合日常数据分析。

它和传统数据库最大的区别之一：有些场景下，不是必须先把数据导入数据库后才能使用。

而是可以直接面对数据文件：Excel、CSV、各种分析文件。

其中Excel、CSV是普通人最常接触处理的数据文件。

以前很多人的数据流程：文件--格式转换--导入数据库--SQL处理--导出结果--格式转换

而DuckDB让流程变成：文件--SQL分析--导出结果

数据库和文件之间的距离被进一步缩短。

比如Excel数据，可以直接读取后参与SQL分析。

甚至一些压缩文件中的CSV、Excel，也可以直接读取，减少中间解压和整理过程。

这也是为什么我认为：

DuckDB让数据库能力开始真正进入普通用户的工作场景。

为什么现在更推荐DuckDB？

如果想在日常工作中开始使用SQL，个人更推荐从DuckDB开始。

不是因为它取代了Oracle、SQL Server这类传统数据库。

它们解决的问题完全不同。

大型数据库：解决企业级系统问题。

DuckDB：更适合个人分析和数据处理。

很多个人工作场景，并不需要：服务器、复杂部署、权限管理。

需要的是：数据来了，可以快速分析。

规则确定，可以重复执行。

流程形成，可以持续复用。

而DuckDB刚好处于这个位置。

SQL不是为了处理“大数据”才存在

很多人学习SQL，是因为认为：以后可能会处理大数据。

但是实际上：SQL真正改变的，不只是数据量，而是工作方式。

几千行数据、几万行数据、几十万行数据。

只要存在：重复处理、固定规则、周期分析。

SQL都有发挥价值的空间。

以前是：花时间操作数据，输出结果。

后来是：花时间设计规则，输出SQL脚本+结果。

前者后期重复时，基本花费相当时间，时长是分钟或小时单位

后者重复时，每次都是执行SQL时长，单位基本是秒。

同时后者在使用过程也积累了一些可以重复使用的方法。

最后

Excel依然是一个非常优秀的工具。

它适合快速查看、编辑和临时分析。

但是当工作开始出现大量重复的数据处理时，也许应该重新考虑：

是不是可以把一部分工作交给 SQL。

数据库并不是只有大型企业才能使用。

SQL也不是只有程序员才能学习。

随着SQLite、DuckDB这类轻量数据库的发展，数据库能力正在逐渐下沉。

普通用户，也可以拥有属于自己的数据处理工具。

而这可能就是未来个人工作效率提升的一个新方向。

后续会在这个公众号里，持续分享工作中的SQL脚本和实战案例，如果你也在和数据打交道，欢迎关注。