我的天

晚上洗澡的时候我一直在想着某个Power Query的问题。某个功能我曾经试过用别的步骤去实现，但是到了最后一步的时候，发现某个东西算不出来，所以我就放弃了那个方法，文件也被我删掉了。晚上，当我遇到一个新问题的时候，我觉得用下午的那种方法才最容易实现。晚上洗澡的时候，我突然意识到，实际上下午的时候我几乎成功了，只剩下最后一步。当时我没想到，其实可以用一个以退为进。我可以做一个判断，如果if的判断等于空，就计算，如果不等于空，就是继续保留某数据。我并不知道如何修改PQ里某一列的数据，于是我的实现方法是新增一列对旧的那一列判断，然后把旧的那个删掉，新的那个重命名。这样就解决了下午我最后我没解决的问题。虽然这样做有点笨。高手一定不会这样做的，高手一定会有一些暂时我还无法参透的各种套叠解决问题。

要实现某个功能，最终我用了31行，更之前我用某个其它方法做出来的那个一样多，但后来的方法显然更容易理解。因为整个代码都是我手写出来的，命名也更加人性化。当然其实我也可以对系统自动生成的名字做修改，达到类似的颜值，但是某些自定义函数光靠系统的可视化窗口无法做到。经过这一番折腾以后，我更进一步地明白到之前我已经模仿做到的模糊查询到底做了什么操作。和之前我模仿回来的模糊查询比起来，这一次我实现的功能要麻烦一点。一开始的操作二者挺相似，模糊查询做完第1步以后，基本上就只剩下删除列和排序了，而我做的那个在完成的那一步以后，只不过是刚入门。我也不知道这一次摸索我到底是怎么折腾出来的，那显然，如果没有看见星光的M语言课程，我会继续迷糊。也正是因为第4节里说到了上下文，说到了新增列判断条件以及上下文的使用，才可以让我顺利流畅地通过第1步，也正是因为经过这一次练习，我觉得我已经略微掌握了上下文那个东西。

软件这种东西，光是看教程、听课，而不于实际操作，是没有用的，因为那个东西不会入脑。要形成条件反射，要让那些技能成为自己的东西，只有通过思考和练习。高手和低手的区别，我觉得大概在于高手的思考时间远远不需要那么长，所以他们可以有更多时间练习，而我这种低手，要在思考那里花好些时间，后来的练习当然比不上人家。基础的了练习尚且不够，就更不用说读懂练习中的异同。这种东西，在我高中的时候特别明显。高手在刷题的时候，我还在理解，至于为什么高手可以理解得那么快，至今，我都想不明白。大概这个东西不是想就能明白的。

经历过纠结以后，我觉得自己的脑洞又大了不少，在遇到问题的时候，我奇怪的思路又增加了一些。就是这些旁门左道的扩展，让我在处理正统问题上，貌似又更进了一步。

追加查询这种事，2句话搞定，这实在让人太震惊了，但实际上，两句话里其实暗藏了许多玄机，高手用一句话完成了几个步骤的事。能做到这样，绝对是因为对函数这种东西了如指掌。

source = Table.SelectRows(Excel.CurrentWorkbook(), each List.Contains({“表1″,”表2″,”表3”},[Name]))[Content],
result = Table.Combine(source)

Excel.CurrentWorkbook()这种东西通常我们都是后面搭配{[Name=”某表”]}使用，那是点名使用，一次只能一个，但实际很多时候合并工作簿都是里面同型号的表全部合并，如果全部都用这种，得列多长的清单。高手的代码里，还可以把List.Contains变成Text.Contains，如果是list那就是点名要哪些或者不要哪些表，如果是text那就是直接筛选表的关键词，包含哪些关键词或者不包含，各有所长，都能实现。如果命名很规律，那是简单到爆炸的事，即便命名不规律，也能用排除的方式忽略某些不想合并的表。你或许会说，既然是合并工作簿，为什么不直接用从外部文件的工作簿获取呢，那样直接就到位了，选择的时候也很自由，因为那是可以可视化操作的，而且不需要实现把工作簿加入到表，我觉得最根本的区别在于移动文件的时候，外部获取你还得更换数据源，当然了，这个可以通过自动获取数据源地址的方式实现，但直接CurrentWorkbook是最没有烦恼的。要把工作簿里所有表都变成超级表，这在收集和整理表格的时候其实也是有难度的。所以这种一次性用CurrentWorkbook包揽工作簿的方式我觉得最好不要超过10个，3-5个是最合适的。通常，如果用追加合并，可视化系统生成的是Table.Combine{{“AA”,”BB”,”CC”}}类型的多个表格列表，而高手的代码里，source其实就是一个表格的列表。轻描淡写之前，处处暗含玄机。要做到这样得非常清楚每个函数需要什么数据，可以生成什么数据，玩弄的正是表格、列表、记录的互相转换。

同样是contains的功能，list的是后面跟前面对，对上就true，但text是前面跟后面对，对上就true。对我这种初学者来说，这是很迷糊的事，谁先谁后到底是最定义这些公式的，为什么要这么郁闷呢！有这种吐槽大概因为我不熟悉，对高手来说估计是没有疑问的。到底建立这些M函数的时候，他们是怎么分配工作的呢？类似的功能一个人负责？某个统领下的函数一个人负责？最后有没有对“.”以后相同，功能类似东西做比对呢？对我这种懒人来说，类似的函数能用复制粘帖修改就不会用重写这一招，但显然，他们的脑洞估计不是。

看书对照操作是一回事，融会贯通又是另一回事。

昨天我实现了前天还不能实现的功能，用起来果然很爽。Power Query拯救了用vlookup公式导致源数据界面输入卡顿的问题。关于vlookup的卡机，据说用Power Query或者Power Pivot都能实现，而且据说PP的效率比PQ还要高。PQ现在我知道应该在哪里写代码了，但PP的DAX到底在哪里写，至今我还没找到。相对来说，我觉得PQ界面的按钮多一些。PP的按钮感觉跟数据透视表很类似。这就意味着，厉害的功能就隐藏在普通的东西之中。PP跟PQ比起来，函数的数量少了很多。用过的人都说，PP要比PQ简单，PQ就像一个谜一样。

前几天当我搜索，PQ教程的时候，发现了里面居然有递归。在谈递归的时候，把迭代也放进去了。迭代跟递归有什么区别现在我还不知道，但我知道递归和循环有什么区别。当某个函数的控制可以把判断和循环都用上的话。再加上700多个已经事先设定好的系统函数。PQ要实现一些神一般的功能显然是理所当然的。只有你想不到，没有它做不到，但前提是，要做到某些功能，光靠可视化版面，根本不可能。要在高级编辑器里自行折腾，或者在自定义的地方选择性折腾。光靠鼠标点击按钮是没办法把PQ的函数层层套用的，没办法一次性套用多个函数，某些功能就比较难实现了。对小白来说，要掌握所有可视化的按钮，尚且没那么容易，但是真正的高手，是必须自己写码的。

PQ用的是M语言，貌似我在VSCode的插件里面没找到相关的东西。里面有DAX的插件，可以自动补全和语法高亮。M语言更需要这种插件，因为光是函数的大小写就会把人搞疯掉。英语输入默认全部都是半角，但是如果我们的脚本里面还有中文，那就意味着中文跟英文得不断切换。光是逗号这种东西就会搞死人。而且我们的脚本里面，还不可能不出现中文。的确，函数可以起英文名字，但是，要处理的数据的列名，必然有中文，因为表格的内容有中文。我不知道那些写码的人是如何克服这种中文英文切换标点符号的问题，反正我是觉得，双引号，逗号，小括号这种东西经常让我很烦恼。不过幸好，据说，Office 2016以后的PQ，在写码的时候有自动补全功能，的确现在我的Microsoft 365可以这样，不仅仅是函数可以自动补全，连变量也可以自动补全。我不知道其他人写码的时候是怎样的，反正自从我习惯了python以后，我实在不能接受没有规范缩进的脚本。也正是因为有了python的习惯，所以我也默认把缩进从tab换成了4个空格。习惯了在VSCode里4个空格是4个圆点，现在PQ里没有这种东西。总让我觉得很不智能。

所有office文件都可以修改后缀，变成一个压缩文件。里面你看得懂或者看不懂的东西实际上就是数据以及你执行的步骤，所以PQ虽然有可视化界面，但实际上，它的高级编辑器让我觉得，那东西还原出了office软件数据处理的本身。

今年我的计划是学R语言，但实际上，我迷上了python，接着现在，我又迷上了M语言。

从完全不用Power Query到天天都用那个东西，我感觉这实在太不可思议了。这种变化仅仅发生在一周之内。一周前我还在纠结，为什么我的Microsoft 365用不了Power Pivot和Power Query。自从我重新能用PP以后，我就在不断地探索，但是平时我处理的东西已经没什么可探索的了，因为那都是用了几年的成熟方案。我觉得已经很顺畅了。如果要再高效一点，就是把所有东西放进数据库，但我又不想真那样。并不是说我的确做不了，而是我还是想把这些东西用普通的office软件解决，毕竟实在说不准以后会怎样。会不会某一天我不续费365，又或者是我可以这么操作，但是和我搭档的人无法接受我的高端。如果我只是把软件交给他们用，这对他们来说学不到什么东西，他们只是用软件。当然这对我来说是很有好处的，因为无论是软件的使用还是软件的开发，我都了如指掌。这也正是我一直都很着迷的事。我不仅仅喜欢研究某一个部分，从某一个部分开始，我会快乐地发散开去，无论是纵向的还是横向的，最后全流程我都熟悉了。大概到了那个时候，我会换另一种东西开玩。

说回PQ这个东西。其实几年之前我已经听说这个强大的存在。Office 2003有个MS Query，但那个东西跟PQ其实是两回事，MS Query更类似于数据库的界面，PQ我觉得应该是Power BI的一个组成部分。Power BI除了PQ以外，还有Power Pivot和Power View。说是这么说，实际上我没用过Power BI。PV这个东西非常强大，动态展示数据，五颜六色，各种花式，但问题是，即便我能把那些东西放在网上，当我要交作业的时候，领导还是比较喜欢长篇大论。其实我更倾向于做个PPT，然后由我上去讲我的想法，而不只是写一篇纸上静态的东西说明问题。

PQ让我着迷的首先是逆透视。逆透视在从前的教学里，唯有通过数据透视表高级处理，现在貌似我已经不记得应该怎么用了，但是PQ非常简单，没有做不到，只有你想不到。二维表变一为表是秒杀的事。既然可以逆透视，当然也可以透视，所以你也可以把一维表变成二维的，为什么会有这种需要呢？之前我也不觉得要这么干，但昨天论坛里某个网友还真提出了这样的要求。他要合并两个表的数据，其中一个表的某两列得先进行透视处理。为什么会这么折腾呢？从原始数据看来，我不觉得他的表有什么问题。如果是我设计的原始表格，也就那样了。最终，他想做到的效果也很正常，因为那一大堆的数据，最后要得到的，其实也就是为了看那些东西。一开始，我想用PP连接两个表。结果发现连不上，说那不是唯一的ID，我有点理解为什么会连不上，因为实际上两个表除了某列数据有共同点以外，其他东西完全不相干，但是PQ却可以把他们用接近变态的方式粘合起来。从最后组成的大表结构看来，的确很乱来，但是要的不就是最后的数据吗？整合之后，一点问题都没有，当然，如果你要筛选两个表格，关联部分以外的字段肯定会出状况，而且这个状况是无法避免的，因为那些根本是不共有的信息。

我对PQ有好感的另外一个原因是那个东西有高级编辑器这种神奇之物。那种感觉就像PQ是一个可视化的网页制作软件，而它的高级编辑器就像是源代码。路人甲玩的是可视化，高手操控的是源代码。PQ的源代码用的是M语言。这是一种介乎于函数和编程语言之间的东西。能玩好这个的人没多少，能玩好这个的人绝对会让别人觉得是个神。数据的整理变成弹指间的东西，非常的伟大。几句代码就能解决平时我们只能靠努力，甚至非常努力都仍然解决不了的问题。

是网友们的问题，让我的脑洞又大了。