我的天

智能化这个东西，我感觉是一个深渊、无底洞。理想很丰满，现实很骨感。几乎可以这么说，现在单位的所谓智能化，无论是单位的作业系统，还是集团公司的OA系统，都是一个四不像的东西。也不是说它们不能把某些数据呈现出来，关键是明明那些明细数据都已经收集齐全了，但是最终那些如何汇总可以这么说，两边都是一团糟。为什么都这么糟糕呢？为什么就不能把数据整合到一个让人舒服的模样呢？最基础的东西不断地让我填，填了一遍又一遍，但最后明明这个汇总结果根据已有的基础数据是完全可以组合生成出来的，但出来的东西就是非常的糟糕。比如说把不应该拼接的东西拼接在一起，结果那个结果就是还不如直接没有，因为放在那里只是碍眼而已，没有任何实质效果。两边的系统都存在这种问题。这是技术上实现不了的吗？显然不是。

因为浪潮现成的那些导出让我们的活没法干，所以我们单位的人也就只能写数据库查询，把我们想要的那些明细数据整合出来，然后通过Excel查询数据库，最终输出。我自己也在做同样的事情，我通过的是Excel的VBA，查询的是多个我自己的原始数据，有些数据只是一个复制粘贴，但有些数据需要日积月累手动录入，之所以不能直接使用系统的数据，因为某些数据是需要进行拆分微调的，某些则需要人肉添加某些必要的字段。为什么浪潮那里就不能把那些字段直接带入呢？还有那些微调，本来是不应该存在的，之所以存在，就是因为发生了一些非常规的业务。某些人觉得这么干没有问题，但实际上他根本没有考虑到我们的系统不支持你这么脑洞大开。再深一层的考虑，为什么会不支持？因为那的确不是一个白纸黑字明码标价说明可以这么操作的事情。难听一点，可以称之为违规，因为规范里根本没说过可以这么干，但如果人情一点，可以说这也是一条没什么问题的操作方式，只是原有的那些不够全面。最终到底认可还是不认可就看你怎么解释，听你解释的人是如何理解、有多大的容忍度。

无论是我的同事查询数据库，还是我用VBA查询多表，最终大家都是根据已有的明细数据生成一个我们觉得舒服、我们需要的那种表达方式。为什么我们能做出来，但是那些所谓系统却做不出来呢？浪潮做不出来，可能是他们根本没有在那个地方用过心。致远做不出来，居然跟我们说是因为我们给的钱不够。实际上有些功能是一期的时候给过钱，写过需求，要求他们那么干的，但实际上他们出来的效果不符合我们的要求。在这种情况下，你应该给我修正过来啊，但为什么没有呢？写需求的人没发现，发现的人不知道如何去反馈。基层单位不知道集团公司当初写的需求是什么。集团公司要基层单位使用这套系统的时候完全没有任何的指引。基层单位只能摸着石头过河，没有手册，没有讲课。我也不知道我应该看到些什么，不应该看到些什么。当我看到一些理论上跟我没有关系的东西的时候，我只能认为可能那套系统就这么个样子，就是可以让我看到，虽然那对我来说没有什么意义。

无论是浪潮还是致远，他们觉得基础数据的收集是他们得做的，而后续的汇总查询是额外的工作量。实际上换一个角度考虑，如果你能把那些字段构直接交给用户，让用户自己去设定流程查询，你完全没有任何工作量。你只需要教会用户如何组合就好了。汇总数据，无论是1个还是10个还是100个，都只是用户发挥想象力的事情而已。他们不敢放开这个，可能他们就没试过放开过。为什么会这么说呢？因为中兴云在介绍他们的系统的时候，就曾经说过这么一条：用户可以自己设定流程，生成自己的查询汇总数据，具备很强的拓展功能。说是这么说，实际上他能不能实现我不知道。显然即便开放了，这也不是一般人就能做得了的事情，起码他得懂一些东西。提出某些汇总需求的人得明确讲出他的数据是怎么来的，然后那个懂一些的人才知道该怎么给你凑出这个玩意。现在我估计情况是要汇总数据的人没有说清楚那是怎么来的，其次那个懂一些帮你设置那个流程的人不存在。

明明打通任督二脉就能轻而易举就解决的问题，现在翻来覆去、耗费大量人力物力。

周三的下午跟往常一样，我点一下自己写的ADO+SQL+VBA的跨表查询文件，结果发现之前一秒就能出结果的东西等了好久，鼠标在那里转圈，我都甚至怀疑是Excel不知道因为什么原因卡死了，但我又有理由相信这不是卡死，因为当VBA要运行很长时间的时候，就会出现那种假死的状态。以前我遇到过这种情况，当我要查询一整年的平均库存的时候，就会这样，如果只是查询一个月的，没有问题。之所以一整年会出状况，是因为需要处理的数据的确有点多，如果我用的不是Excel的VBA的SQL，如果我要做的那个平均库存是在数据库里，用正儿八经规范标准的SQL做，我感觉不需要那么长时间。要长时间运行，无可避免会出现假死状态。周三下午，我就经历了一次，但我觉得那个查询不应该会假死。那个查询文件我用了接近两年，一直以来都没什么问题，因为数据不多，很简单，所以正常情况下，一秒之内出结果。其它查询可能需要的时间长一点，因为涉及的数据量比较大，但是这一次让我卡死的那个，一直以来，当我测试成功通过以后，就没有卡死过。

为什么会这样呢？我把自己写的所有查询文件全部都点了一遍。我觉得既然最简单的那个都要卡24秒，那些之前需要更长运行时间，会让人疯掉。测试结果让我有点意外。我猜想会更疯狂的那些居然没事，跟以前一样，运行时间没什么区别，但有些我感觉没有难度的东西，反倒卡住了。最卡的那个卡了97秒，实际上那个查询平时只需要0.5秒。

遇到这种情况，首先我不觉得是因为我的查询文件出了状况，因为这几天它没改动过，除非有人动了我的电脑，但这个几率太低。我觉得出状况最大的可能性是那个源文件的结构发生了某些变化，因为我引用的是Excel文件。用的那个范围是一个超级表，而如果在那个超级表以外的某个地方出现了一些奇怪的数据，比如说在纯日期的列里面出现了文本，那么就会导致在SQL转化数据的过程之中出现一些意想不到的事情。为了避免这种事情，我把源数据的那些空白行和列全部都删除处理。这就保证了我的原始数据是符合规定的，和以前的格式是一致的。接下来我觉得这会不会是更新的问题，所以我对windows系统以及Microsoft 365都进行了手动的更新。这两个东西的确都是需要安装更新的。更新完成了以后，问题依旧。

接下来我有两个选择，一个是就这样等死，反正现在的情况也不是出不了查询结果，只是用时很长而已。万一这真的是微软升级的bug，说不定哪一天他们就会解决掉，但也说不准他们永远都不解决这个我认为是bug的问题。第二个选择是我主动出击，逐个测试VBA查询里的语句。找出那条让我运行时间很长的语句，然后判定到底是什么原因。

那个理论上一秒就应该结束的查询，实际上是Excel工作表里面汇集了多个汇总查询。我只是把结果都在一个页面展示而已，所以首先，我要找出导致最终结果很慢的是哪个查询。这是一个反推的过程。让我有点意外的是，那些涉及很多数据的查询居然都没有问题，一个我觉得根本不会出问题的问东西里居然出问题了。出问题的那个查询实际上只涉及了一个字段两条数据。这简直让我震惊了，怎么居然这样呢？

这个问题是我之前没有遇到过的，但从发现这个奇葩之后，我觉得自己有点跟那杠上了。

每次写统计分析肯定会让我想粮价这个事情。除此以外，我对这个东西一点都不关心，但每次要写的时候我都会很为这个发愁，应该去哪里找到这些粮价呢？这一次因为我玩得比较大，我需要的是2018年7月到2023年8月的粮价。横跨那么多年，想想都觉得应该很疯狂，真的要去找的时候感觉更疯狂。粮价这种事情以前我也有找过，每一次都是临急抱佛脚，但是抱完佛脚以后，我也是有坚持过一段时间持续去人肉爬虫，但是爬了一段时间以后没有继续下去。在我还可以人肉爬的时候，那些价格大概一周出一次。对我来说一周这个频率太长了，所以过上一段时间就会忘记，而且别人出价格的时间还不那么稳定，虽然说是一周一次，但是说不准就是哪一天，可能是周一可能是周三，也可能是后补回去。被这样拖来拖去，久而久之我也就不记得了。这一次因为要找的跨度很大，我要做图的话，就没有必要把数据找那么细，大概一个月一个价格就行了，至于如果一个月变动很大，那就人肉平均一下，毕竟5年的价格下来，即便以月为单位也是个不小的数目，我需要表达的是整体趋势。

如果粮价时间跨度不是很大，只需要一年或者半年的话，一个地方大概就能把东西找齐，但现在我发现在一个地方找，根本找不全，最根本的原因是有些之前我人爬价格的地方做到某一年就不再干下去了。有些有新价格，但是最早的那个是2022年。有些有2018年的价格，但是他们干到2021年就不干了。还有一些地方比较屌丝，在网页上他们要会员注册，然后给钱成为VIP，才能看到数据。在公众号上他们展示了一些试看文章。试看文章里有我需要的数据，但问题是那个是周报，这就意味着，如果我要拿到2018年的数据我起得起码得翻到2019年头，因为通常那个微信公众号的试看文章展示的图表是一年的玉米价格曲线。显然公众号就只是吊一下你的胃口，最终他们想做的是你去他们的PC版网站注册并交会员费，于是我也就只能用最常规的方式去刷取他们微信公众号上面的历史文章。历史文章这种东西理论上是无限的，但那是一个动态加载的过程。那个历史文章的页面比较屌丝，必须要在微信的浏览器上打开，一般的浏览器无法直接打开。这就意味着实际上在打开的过程中我个人的账号给绑定了，限制了我的刷新频率。在那个历史页面，你只要点击进去了，就会直接到达那个文章，当你返回的时候又回到了一开始的那个列表。我需要加载很久很久以前的历史文章，所以我就得不断滚动、不断加载。当我好不容易到点2020年初的文章的时候，一个不小心点错了，我应该在广东玉米，结果我却点了饲料的，文章打开了，但是却不是我想要的，再次进去重新刷鼠标，却发现无论如何都再也load不出我要的列表。不仅仅是电脑端无能，手机端也被限制了，所以估计可能好长一段时间我都不能再加载到这个公众号上面的历史文章列表。如果腾讯非常狠，可能这个公众号上的历史文章列表我永远都刷不开了。所以为什么会有这么屌丝的设定呢？明明文章是有的，但是你却看不到。我明明只想要以前的文章，但是你永远都是用倒序去排列，不允许我对时间进行任何筛选，这样的话你就强迫我不得不一次又一次动态加载你的列表，加载多了你又禁止我这个行为。如果你有记录过我这个加载的意图的话，就会发现我并不是要打开你们所有的文章。我也没有复制粘贴偷龙转凤之类。这样的防止爬虫方案直接把我这种本来用途很正路的用户给挡在门外。

数据库网站很多，各种类型都有，但是很多连试看的机会都没有，我怎么知道你们有的数据就是我想要的呢？现在的竞价交易在国家平台，所以国家肯定有所有竞价交易的数据。为什么国家就不能提供一个查询渠道让大众去了解行情呢？

每当遇到收费的数据库都会让我有很强的破解欲望，虽然我知道我根本做不到。

每次都定下一个小目标，然后去实现。结果发现一天多一点的时间居然就能搞定一个问题，这种进度有点出乎我意料，因为之前的那些问题让我挣扎了好长一段时间，起码有两三天，之所以后来进度加快了，大概是因为我明了了我要做什么，但是尽管是这样，还是会遇到很多奇奇怪怪的问题。

这周初我解决的是批量生成月度核对表。我把这个任务分成两个步骤，一个是查询到底要生成多少，接着就是把查询到的结果生成文件，但是那个结果跟文件又不一定是完全对应的，根据不同条件可能10条查询结果最终会生成9个表。因为实际上某些条件是需要合并才能得到我想要的文件。在怎么设定条件，如何进行循环方面，我纠结了好长时间，几乎可以这么说，上个周末我一直在做各种尝试，为的就是最终实现这个目标。

在完成了批量生成月报以后，接下来我要做的是生成某个仓的分仓台账。相对于之前的月度核对表，这个单仓台账相对而言条件是固定的，而且必定只生成一个文件。同样我首先做的也是做一个查询，查询一下这个仓到底有多少条记录是可以生成分仓台账的，我又要生成具体哪一条。有些是无法自动实现的，因为实际情况是某些仓某些筛选条件是不一样的，但实际上应该反映在同一个分仓台账里。这个时候就需要手动合并一下条件。这种例外的事件不确定会在什么时候发生，所以必须给手动留有余地。之所以分步骤，其实一个很重要的原因是其实有时并不是为了生成分仓台账，只是要查询一下这个仓的情况。批量生成月度核对表，我花了好几天的时间，但是生成分仓台账，我只花了一天不到。

接着，我研究的是库存查询。在不同的条件之下进行库存查询，最后的结果是以一个透视表的方式展现出来，根据不同的查询条件透视的项目不一样。虽然我想到透视的项目是不一样的，但实际上在我研究的过程中，我先在单一的条件上做尝试，当单一的条件生成的数据没有问题以后再把它扩充到动态条件。因为有了之前月度核对表的锻炼，所以动态条件该怎么做我是有点底的。

SQL最基本的查询语句基本上我已经比较熟悉，这一次库存查询最后一步需要做一个透视。透视这个东西是我之前没有尝试过的，虽然我是Excel数据透视表的超级粉丝，但是在SQL里面控制这个东西，我还是很不在行的。所以到底什么条件可以控制，可以控制到什么程度我是不知道的。教程通常都只是最简单的那些，用上面的数据你重复100遍都不会出什么幺蛾子，但是在实际情况下你会有更多需求。比如当我要控制被透视列的排序的时候发现好像在Excel的SQL里无法做到。即便我在透视之前那一步已经排好序了，但是透视的时候依然是我行我素。让我比较挣扎的是，在透视之前我已经通过分组合并计算出被透视的列的合计数了，但是透视之后合计混在了那一堆被透视的字段中间。最后我已经想到不计算合计，在SQL里面生成透视以后输出到数组，我在数组里面做合计。就在我几乎要放弃的时候，原来合计可以通过在透视的select里用一个聚合函数实现，这样的话透视之后的表格就是先是条件列，然后是合计，接着是那些被透视的列。虽然合计不是放在我想要的最后面，但起码放在了最前面。

库存查询研究过程中让我纠结的问题是什么，明天继续。

上周开始我就在用Power Query跟Power Pivot做跨表的数据合并。与其说是数据合并，不如说是数据查询。一开始我用的是PQ，因为从感觉上来说好像 PQ做这个就够了，但当我把东西都做出来了以后发现PQ很多规则都非常奇怪。让我觉得要试一下PP到底怎么样。根本原因是明明数据量很少，但是PQ的运行效率却很低，而且运行效果很不稳定。从0-1生成PQ的过程比较挣扎，虽然整体的思路我都有，我知道我要有什么后效果。但是该如何实现还是花费了我不少时间，比如查询参数应该用什么格式的表格表达出来。一开始我把4个日期和3个文本以左右的方式表达。的确这样的取数没有什么问题。虽然实际上PQ是用列去进行各种魔法运算的，但要精确定位到某个单元格也就是某条记录一点问题都没有。后来当我要用PP，那个东西至今我不知道如何在某列混杂着各种内容的单元格里获取我需要的数据。要顺畅用起PP，我得把日期参数跟文本参数拆分为两个表格。文本参数我不是直接给PP用，而先给PQ，所以横的竖的都无所谓。日期参数是直接在PP里做限定，所以必须以PP的规格去设定表格的形式。这仅仅是参数的表达，是最简单的东西。如果以普通人的视角考虑，某一列数据日期和文本混搭一点问题都没有，但是从机器的角度考虑，从我使用的那两个软件的规范考虑，显然这样是不行的，又或者说不是不行，是你为什么非得以一种如此随意的方式去做这么简单的设定呢？混搭的方式，肯定也会得到你想要的结果，但是对软件新手来说，绕那么一大圈显然就比较费劲了。

用PQ和PP的方式做出来的两个查询都能实现我的目标。数据都是没有问题的，但是一个文件体积很大，一个查询时间很长，且查询效率忽高忽低不稳定。这两个都不是我想要的。我不过是想做一个查询而已，很简单的东西，实际上我就只需要一个结果。那个结果以我想要的方式输出，后续的格式化纯粹是让我自己觉得比较顺眼好看而已。但是这两个Microsoft 365内置的Power都不能达到我的预期目标。

在挣扎之前，我觉得应该用PQ实现目标，但实际上出来的效果跟我想象的相差挺远，最根本的原因是我实在不太理解PQ的数据处理。PQ是用来做数据清洗的，所以从某个大表里获取数据，然后进行各种筛选，接着以各种目标形式输出表格，理论上这是很简单的事情。这大表的查询几乎可以这么说，一定是引用外表，因为源数据已经很大，你不可能在上面直接运行，虽然其实一直以来我都是这么干的，但是那个时候我并没有进行跨表操作。从现在的运行效果看来，即便是同一个代表同一个源数据，最终需要以几种方式输出分组筛选后的结果，最终要生成多少个查询效果，我就得把那个源数据查询多少次。理论上怎么会干这么傻的事情呢？直接把大的源数据查询一次缓存起来，往后就不需要调用了。但问题是从我现在的观察看来。最终我要多少个查询结果，他们就同时开始查询多少遍，于是有些时候就会导致有些查询结果失败，你得刷新再来。原因是这个查询正在使用那个源数据，那个查询也在用那个源数据，为了抢那个源数据打架了，抢不赢那个就刷新失败。都是查询一个源数据，我考虑过既然无法避免它们一次又一次查询，那么我就把那几个查询按顺序来，完了一个再到下一个，但实际上这个也是无法控制的。都说VBA是单线程的，但是PQ是多线程的，单线程虽然慢，但是多线程这样打架，最终反而得不到我想要的效果。从理论上说，我把那个大表一开始就缓存起来，后面的都用内存缓存，这很正常啊。我设置查询的优先等级，先刷新一些，然后再刷新另外一些，这也很正常啊，为什么却没有一个很直接的实现方式呢？有些人想到要用VBA去控制PQ的刷新顺序，但是VBA却很难判定某个刷新是不是完毕了，VBA也很难做到这个刷新完毕了再开始下一个。

接下来我要试一下python方案，我的目标是查询时间小于10秒，生成的文件小于100K。