我的天

花了一整天的时间去做python版本的发跨表查询，最终还真的被我做到了，唯一有点小瑕疵的就是出入进度里我还没有实现批次小计。我基本已经想好需要一个什么样的数据处理，但是怎么把那些东西结合起来我还没有一个成熟的思路，估计会有一些类似的案例，我可以参考一下。

之所以这个脚本居然用了一整天，是因为最后我算了一下字数，居然有4000多字。因为我用的是VSCode，所以实际上敲代码已经很高效了，因为几乎所有符号都会配对出现，一旦有手误的地方基本上都会提醒，但是有些东西是VSCode不会提醒我的，比如我要用到pandas各种格式的数据，有些事不能直接用print打印出来的，必须要用个循环才能把那些东西展示出来。如果我用python处理Excel，我会用xlwings进去，然后用pandas。之所以用xlwings，因为这个东西支持Excel的版本比较多，老一点的插件有的只支持xlsx有些不支持xlsb，有些仅仅支持xls，而我选择的这个xlwings基本上我用的Excel格式都支持了。现在我主要用xlsx和xlsb。因为做这个python查询之前，我已经在PQ和PP上做了两遍，所以我完全知道自己要做些什么，但具体那些东西该如何实现，应该用什么样的表达式去实现，是我花时间的地方。

昨天之前我对pandas里面的dataframe并不太熟悉。我知道那个结构很类似于Excel的表格，但实际上用起来又跟表格不太一样。我觉得那个东西最好的地方就是不像PQ那样，经常被高手套叠起来，于是你想半天都搞不懂那到底是什么。作为一个不是python新手的人，我还是喜欢用短语句完成，然后再连接起来。自学python让我觉得最成功的地方在于我喜欢用for循环，而且还非常习惯使用套叠循环。如果在我大二学C语言的时候，我也能把循环玩得这么溜。估计我就不会为冒泡法这种东西发愁了。

虽然花了一整天时间，才终于把这个东西整出来，但我个人感觉还是比较愉快的，尤其是敲代码的过程，因为相对于在Microsoft 365的PQ或PP的编辑器里面敲代码，VSCode里敲代码实在太爽了。PP会经常提醒我公式错误，因为PP那个你看不到的循环实在会把你整得很惨。PQ里我不过是删了个文字，不知道为什么它会自动给我加半边括号，所以搞了半天，我都搞不懂自己到底哪里错了，最后发现不知道为什么，多了个括号，又或者在调整某些语句的时候多了或少了个逗号。英文和中文逗号在编程的世界里是有区别的，在VSCode里可以看得很清楚，但在PQ的高级编辑器里。因为字体太小，你还没办法快捷变大，非常折磨我这种眼睛不太好的老人家。

高中的时候我的数学老师经常一节课就只讲一道题，他会用很多方法把那道题解出来。现在，我也喜欢上了这种别人可能非常难理解的行为。

上周开始我就在用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。

近几天都沉醉于做Excel的数据合并，实际上就只是两个表，一个是交易情况另外一个是出入库明细。出入库明细是一个大表，交易情况里面除了交易本身以外还有货款明细以及损溢明细，所以原始表格合计有4个。相对于我之前纠结过的那些东西来说，这几个表有一个数据是必定唯一的，也就是交易情况里面的合同号。损溢明细里一个合同号可能出现多次，货款明细里一个合同号可能会出现多次，出入库明细里一个合同号绝大多数情况会出现多次。所以这些表里，交易情况的合同号是1，其它是多。以前在Excel里面用Power Pivot建立表的关系的时候，我是直接把某一个列拉到另外一个表的列建立关联，但这一次我发现交易情况和损溢明细无论我怎么拉，PP都默认，一是损溢明细，多是交易情况。直到昨天我才知道原来建立表关系的时候是可以不用手拉的。理论上我已经把PP的界面看过一遍又一遍，不仅仅是软件本身，关于它的书我也看过一些，但是好像在昨天之前我就从来没有发现原来有那么个界面。1对多到底谁是一，最重要的一点是哪个表先选定，后选定的表在Excel的Power Pivot里默认是多，但如果二者关系不成立，会建立不了关系。我不知道Excel的PP为什么会这么设定，理论上应该还有1对1，多对多之类的关系，显然在Power BI里面就有，但Excel就是这么神经。用Excel PP默认给的那个1对多的关系，在用透视表的时候，无论如何都得不出我想要的结果，但实际上我想要的那个结果我想了半天也都是合理的。结果手动建立正确的1对多关系后，透视表的数据就正常了。之前，我在Excel的PP上耗了好长时间研究其它东西，之所以有些坎无论如何迈不过，无论如何觉得有毛病我猜是不是也跟这个1对多的关系自动默认给我生成错了。

在玩PP之前，其实我已经折腾了一天的Power Query，之所以从PQ转投PP，是因为我发现虽然我的原数据很简单。最大的那个表才几千行，载入以后进行初次筛选，剩下700多行，另外的那些表只有几行和几十行。但即便这样，它们关联了以后，做全体刷新的时候依然会出现卡顿，依然会偶尔告诉我数据不是我期待的那个格式，所以刷新失败，但实际上当我重新再去刷新失败的那个表，又会成功。在不修改参数的情况下刷新同一个查询，有时都能刷出来，有时一些刷不出来，有时刷的时间要长一点，有时刷的时间挺短，到底这是为什么？各种缓存的参数我都试过了，各种PQ本身设置相关的参数我也试过了，但是PQ自己就是这么不稳定。快的时候可能5秒就出来了，但是慢的时候可能30秒都出不来。折腾了我一天后，当我用PP做出跟PQ完全一样的功能的时候，发现PP的稳定性好很多，几乎不会出现数据刷新失败，大多数情况下，PP刷新需要10秒钟，但是它俩最大的区别在于PQ这个查询文件只有50KB，但是PP的查询文件是800KB，之所以这样，是因为实际上PP把整个原数据都抓过来了。考虑到这些查询文件我肯定会在不同的机器上运行，所以虽然PP可以直接连接某个外部源文件，但我还是选择先在PQ里做一个动态接口，然后再转到PP的模型上，同时在一开始的时候让PQ把3000多条数据出筛成700多条。

10秒钟和不知道到底要多少时间，以及50KB和800KB这两个答案我都不太满意。所以接下来估计我会尝试一下python方案。

我也说不准什么时候问题会向我袭来，比如周五的上午，我正在做着普通的事情，突然就被一个同事叫去了，问我某个关于固定资产的Excel文件到底是什么情况。在我印象之中，我折腾过那个东西，但是具体做了什么，我还真想不起来，因为那是一个非常定制的效果，所以我在那里做了什么我实在不知道，因为完全是根据需求去做某些设定的。明细数据一看就知道肯定就是一开始的表格，但除了那个表格以外，后面的东西是手动输入的还是关联的，我就真不记得了。用的人说那个是关联的，但实际上又好像看不出什么苗头。其中一个肯定是自动生成的，因为那是数据透视表，数据透视表之后，有一个打印的表格。那个东西到底是干什么用的呢？打印的表格里又分了两个超级表。后来在折腾另外一个表格部分数据透视列的时候，我才想起打印的那个表格当年是我用Power Query设定过的。跟数据透视表比起来，那个东西更适合用来做列表类的东西，因为原始数据的编号是空值，所以如果有某两条记录完全一致，数据透视表估计就会把他们组合起来。所以当年我就想出了一个用其中一个超级表作为条件录入另外的那个大表作为数据筛选。这样的好处是除了明细表格以外，其它表格的数据都是查询生成的，虽然他们的表达形式不一样，甚至可以说是定制式的。

至于后来盘点账之类的东西，实际上就是实物账的某一列要进行透视拆分。他们当时根本就没想过可以怎么实现这个功能。无论是之前的使用者还是现在的接收者，都搞不懂实物账跟盘点账有什么不一样。如果只是要把一列透视，自我感觉应该是很简单的，因为以前我就经常用PQ比做这种事，但现在用起来又好像不是我想象中的那样。结果发现之所以这样，是因为以前我用的那些通常都要对数据进行合并。无论是求和类的还是计数类的，通常以求和类的居多，现在用的是不聚合的功能。最终我想出增加一列。然后以那一列不聚合符号作为透视列的依据，然后我再把那些空的单元格全部用空白填充。这样的话就做到了原始数据在一列里有三个分类，目标数据把那个分类分成了三列，最后的效果要在三列对应的单元格上打上勾。效果就是原始数据某一列全部都有三个分类的其中一个，目标数据每一条数据对应的某个分类都有一个勾。说很容易，做我感觉也是很容易的。要实现这个功能，会有一点点绕。用人的思路考虑就是把一个一维表变成一个二维表，实际上也正是在干这种事情，但因为三个分类的对应单元格显示的不是某个数字，而是某个符号。一般的数据透视表不可能实现，经过一些高级设定后Power Pivot可以实现。如果你要用数据透视表表达课程表，一般的数据透视表是无法实现的，因为数据区域是一个标量，只能是数字，不可能是文字，但是在PP跟PQ可以做到。

我的同事的那种烦恼，在我们的这个单位，大概也就只有我能解答了。也不是说我们这个单位的人的能力不行，但是我估计他们不会在Excel的这两个隐藏高级技能上曾经狠下苦功。

又是投篮的第2天，我又没有做任何的运动，依然是坐在那里，整个晚上都把心投在Power Pivot上。但这一次我没有上一次那么好运，可以解决困扰了我很长时间的问题，整整一个晚上我都毫无收获。增长的只是我越来越不知道自己在做什么。但跟前两天相比，我没有一直都耗在那里，而是给自己划定一个底，超过那个时间我就回宿舍洗澡睡觉。在睡觉之前我拿出架子上的另外一本关于Power BI的书，之所以我说那是Power BI，因为那本书大半本都在说Power Query，有部分章节是说Power Pivot，然后是二者的融合。但话说回来，我又不能说那是Power BI，因为那本书是基于Excel而不是Power BI的。

就公式参数的复杂程度来说，我感觉PQ要比PP麻烦很多，尤其是虽然你看上去PQ的界面就只有那么几个按钮，但实际上要发挥 PQ的所有潜能，所有东西都必须在高级编辑器里面完成，尤其是一些非常高效的操作。有些结合的步骤，或许你觉得高级的步骤结合起来跟分步没什么区别，的确对一些一般操作来说，这是可以做到的，但是某些步骤必须层层堆套，而且公式里面的参数有很多的时候，让人感觉脑子就不好使了，从表到列到记录到具体数据。以前我曾经死磕过PQ，觉得非常强大，也非常烧脑。经过一堆操作以后，的确可以做到想要的效果了，但问题是其实那样的效率并不高。所以最终我没有采用PQ的方式，而是直接自己写VBA。相对于 PQ而言，我觉得VBA返倒更符合一直以来我学习其它编程语言的思路，比如说一开始接触到的C又或者后来接触到的Python。但和Python相比，VBA里面有很多默认的公式套路，但起码VBA里的公式套路还可以理解，而不像PQ那样复杂到让你觉得望而生畏。

PP让我觉得很烦恼的地方是可能它就那么几个函数，但是它的组合方式却是千变万化的。你可以用同样的代码在不同的地方放置，但效果完全不同，你也可以写完全不一样的代码实现同一个效果。当然，更多时候你想用一堆代码实现某个效果，但是别说出效果，你通常会被卡在公式审核那一步。我觉得PP让我绝望的地方在于我还没办法以它的思路分步执行，我无法预判如果我这么写的话会达到什么效果。当然这只是一个初学者的烦恼，当我把所有规则都烂熟于胸之后，我觉得这一切都不再是问题。PP我觉得是一个我必须越过去的坎。因为那跟大数据有那么一点关系，虽然这又跟大家说经常听说的那种大数据有很大区别。对我来说，几千上万条数据已经是大数据了。当这些数据经过这种盘曲折叠以后，最终的量可能是数倍甚至以次方的形式增加。我小小的脑袋瓜当然不可能预判出这种事情。

大概我现在的这种烦恼，我有一种方式能稍微缓解一点，就是放下自己手头上要解决的问题，纯粹只投入各本教材中最经典的简单案例。当我把那些都融会贯通了以后，再开始DIY我的方案。