我的天

虽然写Excel VBA已经有好长一段时间，但实际上对一些很基础的知识我还是不扎实的。比如ThisWorkbook和ActiveWorkbook到底是怎么指定的。光说这两样我好像明白，但是当我要使用的时候就感觉老碰钉子。这个东西使用不当，就会经常被弹出错误说某个工作簿里面没有某个工作表，或者说某个工作表已经存在了，不能再新建。不同的写法意味着同样的VBA脚本发起的那个工作簿不一样，有可能要在打开有数据的那个工作簿里发起，又或者直接是在VBA脚本所在的工作簿发起，不需要打开源数据工作簿。除了这个以外，还有就是当刷新数据要放在你已经建立的工作簿的超级表里，该如何删除超级表之前的数据？有两种选项，一种是把数据全部清空，这种情况不改变超级表的格式的，之前已经使用的行会继续存在。这里用的是clear命令，另外一个则是用delete的命令，那样的话原来工作表里面的数据全部删除，只剩下最后一行。二者的差异就在于，如果是用delete命令，如果那个超级表下面还有数据的话，那些东西将会上移，如果你又在那里插入新的数据，可能就会乱成了一团。所以如果在一个工作表里，你安排了很多个超级表，而你又确认那些超级表的格式不会改变，基本上也就那几行，又或者你不确定到底有多少行，但你能确定行数肯定不会超过多少行，这样的话，当你要用VBA把刷新的数据同时写入这些超级表的时候就应该用clear命令，这样的话，刷新的数据就可以指定从哪里开始。如果在这种情况下，尤其是工作表的下面还有一个工作表，你用了delete命令那么当你清空数据再写入数据，下面那个超级表对应的那个区域肯定会乱来。

没人跟我说过这些细节，这是在我摸索的过程之中，经历过一次又一次撞板之后得出的结论，所以如果可以的话，超级表你可以在旁边建超级表，但你不要在超级表的下面建超级表，尤其是那种你根本说不准上一个超级表到底有多少数据的情况下。多建几个工作表，在不同的列起始不同的超级表，一点问题都没有，但在很多人的固有思维里面，Excel就只是一个放表的工具，上下左右都可以放，但是就数据处理的便捷和难易程度来说，超级表的放置其实是得遵循一定规则。

自从知道了ADO+SQL之后，我就经常把这两个东西作为我最大的杀器，把经常使用的Excel表当数据库。但Excel始终不是数据库，最大的差别我觉得是虽然ADO+SQL可以用类似数据库的方式理解Excel表格，但因为Excel表格可以变换不同的格式，所以当在某一列理论上都是数字的那里突然意外有一格被插入了文字，那么ADO+SQL进行转换的时候就会出毛病。刚好你又对那一字段进行了分组汇总，那程序必然进行不下去。通常情况下，人肉很难发现这个问题，因为不知道在哪一行，突然插入一个文字是个意外。一般情况下，调用ADO+SQL把工作表里面的区域读取格式化的时候没有理会超级表的范围。如果有进一步的限定，实际上是可以设定范围的，但一直以来我都没有进行这个行的主动限制。

掌握了SQL以后我觉得Excel自带的那些公式实在太复杂了，参数很多、形式变来变去，有些用乘号，有些用加号，有些用*。

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

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

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

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

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

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

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

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

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

当我终于把功能做出来以后，我却嫌弃出结果太慢了，居然要好几分钟。明明最终我想要的是一个表的合并，为了更快，我不得不拆分为两个查询。第2个查询以第1个查询的结果为基础。其实这么操作，无非我是想利用第1个查询已经得到的缓存结果。那个结果已经被我用表格输出。之前我试过从零开始弄第2个查询，结果发现实在太慢了。如果没有那么多的分组，速度还会那么慢吗？如果只是一个求和，根本无需分组，但问题是，每个批次的东西必须分开计算，然后才可以出现分段的结果。说白了，让我纠结的是一个累计求和。

累计求和这种东西的思路在PQ里通常都意味着新增一列，参数设定匹配某行的某些东西，符合条件就把某列的数据求和。所以实际上这是一个筛选的过程。如果数据很多，筛选肯定会很慢，但除了这样，还能有什么方法吗？据说可以用索引的方法。据说索引的方法比筛选的方法快非常多。如果用python的思路去考虑，我觉得筛选是一个列表的操作，而另外一个是字典的操作。如果不用二分法。历遍列表是非常慢的，但如果要立片字典，历遍是轻而易举的事，而且字典的效率比二分法还要高。所以我应该如何建立索引呢？如果筛选的是多条件，索引大法还能继续管用吗？我觉得现在我遇到的问题那些经常接触数据库的人估计已经纠结过了。这不仅仅是Power Query的问题，这是如何运用数据进行弯曲折叠的问题。只要是数据库，无论是SQL还是其他形式，都会有这种烦恼。

昨天我终于经历了一个Excel要跑好几分钟甚至十几分钟才能出结果的东西，我感觉那没多少数据。我曾经试过把那些东西输出，结果发现输出速度非常慢，每秒钟只处理了不到100个。那些数据粗略计算了一下，可能有超过2万条。为什么加载2万条数据会这么慢呢？这是一个令我纠结的结果，如果把最后的分组都做了，输出的数据只有365条，但如果不做最后的分组，有超过2万条。不做分组的话，那个结果可以在软件里直接展示出来，顶多只需要几秒的运算时间，但是不做分组，把数据输出却有超过2万条，即便我不输出表格只输出数据透视表，依然在输出的时候速度非常慢。为什么对2万条数据进行分组会这么慢呢？除了分组，还有其他快速的方式可以对某条件进行求和吗？整个操作之所以这么慢，除了因为分组，还有排序，还有一些，null转化为0，或者把0转化为null的操作，最后，还有一条我自己都觉得应该会很作死的向下填充。那个结果我花了好几分钟才计算出来，如果让高手去解答，估计运行时间会会是毫秒级的，顶多不会超过三秒钟。

一方面，我很想知道如何提升运行速度，直接拿去问人显然是最显而易见的办法，但在这之前，我想自己先思考一下，毕竟走到这一步已经很不容易，我不想在最后一步认输。这让我想起了高中数学老师的某句经典语录，学习数学几个境界里的最后一句——全而不好（前几句是“不懂不会，会而不对，对而不全”）。

昨天我终于用python写出了把点点转化为WordPress的脚本。这个东西我确信是可行的，因为python的转换过程中没有出错，这就证明没有遇到奇怪的事情。用别人脚本的时候，把转换好的文件上传到WordPress，我总会担心不成功，但我自己写的脚本，我知道该注意些什么，哪些参数是现在的WordPress必须要求有的，所以只要python的转换不出错，我的WordPress导入就不会有问题。因为点点的文章有9000多篇，要从后台管理界面导入到WordPress，会非常耗时间。如果一篇文章需要两秒，完全导入就需要5个多小时，所以我没有做这种事。我挑选出22篇，各个类型都有的，试验导入，结果非常成功，网页的效果也很好，完全按照我的意思生成了。我觉得如果要快速解决问题，估计我得在数据库端导入。之前把文章导入到WordPress，因为要尝试不同的版本，我得不断地导入删除，但删除的文章太多的时候，速度很慢。后来我暴力地在数据库那里直接写删除语句，结果秒杀就完成了。现在我发现了一个更干净的方法。直接把关联WordPress的数据库里的内容全部删掉，这也是一个秒杀的过程，而且绝对不会留下任何的手尾，比如文章删除了，但是分类和标签仍然在那里。可能某些东西已经不存在了，但是计数还停留在一个很大数值，之所以这样，肯定是因为我删除文章的时候不够艺术。与其让里面留那么多乱七八糟的东西，还不如直接把数据库清空。因为我这是单机上的WordPress，我纯粹只是用来测试。这样的删除是最快捷的。大概我从上周，才突然领悟出可以这样。别人之所以要在数据库里写语句删除文章或者标签，是因为不能删掉一些不应该删掉的东西，但我没有这个顾虑。既然在数据库层面可以快速的删除，那么理论上也应该可以从数据库层面快速的导入。之所以有这个想法，是因为我发现WordPress的插件有些是针对数据库的，有些是针对WordPress自带函数的，数据库层面的查询要自带函数快非常多。现在我已经学会了转换适配后台界面导入的文件格式转换。下一步大概我得学习一下如何在数据库层面进行导入。这么高端的做法，貌似之前我还没有听说过。在网站迁移的时候，的确是把数据库打包，然后重新放到别的地方的，但那个数据库是本来就已经存在的。从一个地方挪到另外一个地方，原封不动地，但是我却要把大量的数据以快速的方式导入到数据库，并且还得按照WordPress的脾性建立各种关联，显然这貌是非常不简单，但理论上应该可以做到。

我不知道我的python到底学成怎样了，但起码我可以用那个东西实现我自己的愿望。相比于书本的习题，我觉得实现自己的愿望更有成就感，虽然其中有很多问题完全只能靠自己，没有参考答案。虽然总的来说，脚本不是我一个人写的，我是站在巨人的肩膀上修改而成，但BlogBus和点点的结构还是有差异的。最幸运的是某些我不知道该用什么手段实现的东西前人已经给我指明了方向。昨天我只是把脚本写出来了，接下来我要把脚本优化，一些老是翻来覆去说的句子完全可以把那作为自定义函数。到底什么东西应该泛化，应该泛化到什么程度，这个我还没有想好。昨天之所以可以这么迅速地完成任务，大概是因为在我开始之前先做了个思维导图，明确了我到底要做些什么。基础数据有哪些，应该在哪里取数，需要判断的参数有哪些，各自的参数有什么特性，能不能合并同类项。之前我就写过类似的东西，但是跟思维导图比起来，之前我写的那个真的很水。有思维导图、有专业的思维导图软件，人的思路可以非常快地展开。整体定下来，下面的事情就只剩下一步一步地实现。我做梦也没想到，自己这次居然这么高效。某些我没有把握能快速解决好的问题，昨天不知道为什么很多都迎刃而解了。转换一个30多MB的XML文件，我用了16秒。转换出来的文件大小为22MB。我觉得应该可以更快，但怎么才能更快呢？文件里的数据结构是我没有考虑过的，我是不是应该从那里入手？一些相同的判断，大概我应该做一些合并。

追求更好是没有尽头的。