我的天

我已经不记得自己是如何走上这条写代码的不归路的了，确切地说我已经不记得具体我是哪一天开始研究这个跨表查询的问题。我大概知道顺序是怎么样的，但是具体是哪一天开始我实在已经说不清了。现在我天天都在写，天天都在写VBA、天天都在纠结VBA里面的SQL。我已经不记得这种状态已经持续了多长时间，反正即便是吃饭睡觉，我的脑子里依然想着那个东西。每天就是起床吃早餐然后完成必须做的工作，接着以最快的速度完成打卡，然后一整天都在那里写代码，不管上班还是下班。在这种状态之下上班，那8个小时突然变得好短。因为已经沉迷其中，所以到了下班时间经常停不下来，吃饭时间因此一再拖延。如果不是去饭堂吃，而是自己吃麦片，那就更加是一杯麦片，我根本不知道自己是如何勺到口里的，反正那杯东西我可能得吃一个小时以上。当你完全着迷于做某事的时候，你根本感觉不到其它东西的存在，比如身体的各种反应，比如某些疼痛又或者是饥饿等等。因为我知道我一旦着迷就完全没办法顾及其它事情，所以当我还没迷进去的时候，我就得先把其它必须做的做完了，否则是完全不能自拔的。

之所以出现有现在这个状况，是因为自从我实现了第一个跨表查询的任务以后，我发现一直以来我的很多东西都可以用VBA+ADO+SQL把它们联系起来。那些以前我有数据，但需要这样那样粘贴的玩意现在我可以把它们统一起来通过查询的方式直接获取结果。这样的好处是成功开发以后很省事，但是坏处是这样非常定制化，所以基本没有什么动态可调整的余地，即便设定了很多条件当你想加更多的时候无能为力。还有一个让人觉得挺累的，就是如果我做的是数据透视表，汇总那些事情不是我干的，是系统干的，我管好明细就好，我要什么明细我就搞到什么程度，但如果我得在一个查询结果里面把汇总考虑进去，无论是列还是行，我都得想办法把实现。相对于数据透视表来说，我觉得这种汇总是硬汇总，是设计的人必须得想好的，而且一旦变换某些条件，又得伤筋动骨调试一番。对用户来说，对只看到最终结果的那个人来说，可能会觉得很爽，如果他做过之前那些这样那样的复杂操作，他更加会觉得这实在是太爽了，但如果某个人之前没有经历过那些，他只是直接用这个捷径，从他的角度考虑可能他想知道更多，但是现在已经固定好的方式没办法满足他的要求。所以我还是觉得如果数据是规范的，用Power Pivot的方式把连动起来更靠谱。

PP非常的稳定，尤其是相对于PQ来说，但问题是无论是PP还是PQ，那个写代码的地方都非常不友好。正常的窗口操作基本不会让你挂掉，但是写代码的时候非常有可能直接让你卡死，必须得关掉重来，但是之前写的东西就全部废掉了。现在我之所以会在那里玩VBA，因为实际上我玩的不仅仅是VBA本身，而是VBA延伸出去的SQL。本质上，我在进行类似PQ或者PP的操作，虽然公式少了很多，隐藏技能也就是我至今无法猜透的更多，但就运行效率来说，尤其是对小数据的运行效率来说，VBA+ADO+SQL远远优于PQ和PP。我这里说的小数据是单表不超过1万条，最宽的表不超过30列。

可能，如果我不是用Excel去玩PP和PQ，而是用Power BI去玩，效果会很不一样。

昨天说到库存查询，最后的展示方式是透视表，透视这个东西只要前面做对了，就可以实现，那就只是最后一个步骤而已，但是如何得到透视需要的所有东西呢？在做这个库存查询之前，如果我需要得到某数据在连续日期中的汇总，我会先把那些数据按日期分组，然后选定日期表里面其中一段连续日期，接着用左外的方式连接日期表和数据。但问题是在库存查询中，我最后的结果是透视的，这就意味着被透视的那些字段在没有被透视之前，是各自对应一段一样的日期表，如果最后透视出来的字段有5个，就意味着我有5段一样的日期表，我该怎么表达这个东西呢？

在解决这个多段一模一样的连续日期之前，我首先攻克的是累计数。在SQL里面实现累计数有好几种方式，但问题是不是每一个都适合在Excel的VBA里实现，比如窗口函数over在Excel里面就是不支持的，虽然窗口函数的效率是最高的。对同一个表进行子查询可以实现累计，但问题是这样生成的累计无法用在下一步的透视里使用，接着我在另外一个方案里面看到了笛卡尔积的方法，笛卡尔积得出来的结果跟子查询完全一样，但笛卡尔积出来的结果可以用在下一步的透视里，而且同样的数据，笛卡尔积的运行效率比子查询高（可能是我测试的数据少？）。这个累计数的问题，我在Power Pivot里也研究过。我觉得PP的解决方案跟子查询有点类似。在计算累计数的时候，PP的效率很高。在用PP实现累计数之前，我曾经用Power Query实现累计数。我的PQ解决办法是先生成变化数，然后按日期把变化数累加起来。接下来用日期表跟这个数据左外连接，如果不是天天都有变化数，那么这个合并后的累计肯定会有空行，这个时候再用向下填充的方式补全。用这样的方法在PQ里的确是可以计算出每天的库存，但是效率非常低，所以在那以后，当我要做累计库存，我会直接放弃PQ选择PP。现在我已经掌握了在VBA里用SQL的方法实现。在筛选的日期不多，以及最后被透视出来的字段不多的情况下，效率挺高。比如最终我只需要展示一个月的数据。运行时间通常不会超过0.5秒。我个人觉得1秒是一个分水岭，如果1秒以上才出结果的话，我觉得这需要等待，尤其是运行时间超过2秒，我觉得那得优化了。低于0.5秒的运行时间对我来说几乎是无感的，我可以接受这种方案。

在累计数可以实现之后我要继续研究怎么按照条件需求把日期表捆绑上去。折腾了好长一段时间，都是没什么结果，于是我就去吃午饭了，在去吃午饭的路上，我突然想到，要把这个日期表扩充开来，实际上我不就是要做一个按条件笛卡尔积吗？所以我需要进行左外连接左边的部分，在这个情况下就不是一个普通的日期表，而是被透视项和日期表进行笛卡尔积的东西。笛卡尔积这个东西，如果数据很多会是一个噩梦，甚至会让电脑崩溃，所以所有教程都会告诉你，如果你要的不是这种东西，尽量不要做这种操作。但思前想后，我发现我正是需要这种东西。吃过午饭后，我赶紧去测试我的想法，果然，用笛卡尔积的结果再加后续的操作，我就能生成我需要的东西，并最终能以透视的方式展示出来。

我感觉现在当我把一些最基础的东西用熟练了以后，渐渐地我体会到了一些其实你明明知道，但是你却完全没有料到可以这么用的方法。

既然人可以通过某些逻辑得到某些结果，那么我应该可以按照这些逻辑生成一些自动化的方法，在这个时候，我最讨厌例外情况。

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

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

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

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

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

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

周四的傍晚时分，我突然有点码农蓝调的感觉，因为好像无论我怎么整，前面总有无数的奇奇怪怪的问题。这些问题居然没有大路的答案。原因是Excel的SQL已经被阉割到一种没人能说得清的程度了。我就想知道到底Excel里的SQL有什么样的函数，知道有什么函数，知道函数怎用，才能以各种叠加的方式得出我的招数，但问题是人微软自己的手册都没有说清楚到底Excel里的SQL可以怎么个用法？相比之下，Access写清楚了，SQL Server也写清楚了，不同版本的函数不一样，些高版本能轻而易举函数就能实现的功能旧版本也有替代方法。但是Excel里的SQL像一个谜一样。你得不断尝试直到绝望。因为你拿着那个问题去搜索，没有结果，结果都是其它数据库的，虽然都叫做SQL，但差别真的很大。

的确用VBA+ADO+SQL搭配能解决一些小数据的问题，而且速度很快，但为什么微软在这个基础上还要继续整出 Power Query和Power Pivot，因为他们知道在操控数据方面，VBA本身真的有很多限制。当我死磕了一周以后，我发现VBA要死要活折腾半天出来的东西如果在PP里两下就搞定了，而且那还是在可视化的情况之下。至于PP，那是不允许你用不可行的方式去操控的，所以虽然三个都在考验逻辑，但是在Excel的SQL里面，我觉得对我最大的考验是，我明明知道要那么干，我明明知道用其它工具应该怎么干，但是无论如何我在这个Excel VBA里面就干不出来。

我遇到的某些问题，跟SQL没有关系，纯粹是VBA数组的问题。VBA的一元数组，如果要输出的话，它会在一行里输出，但如果你要把这个一维数组在列里面输出，你就得做个转置。我遇到的问题是，即便我已经设定了转制。系统依然说我的类型错误，最后我是怎么干的呢？明明我那个是一维数组就可以实现了，但为了可以顺畅输出，我硬是把那个东西设置为了二维数组，另外一维完全是空的。这样的话在我输出到单元格的时候只给予一列的空间也就是那空的第二维根本不用管他。经过SQL处理生成的记录集，如果要输出到数组，通常是一个二维数组，那个二维数组跟VBA自己的数组又是转置的关系的，那个记录集的数组编码是从0开始的，VBA默认的数组是从1开始的。如果在VBA里把一个字符串打断赋值给数组那又是从0开始的。在python里，默认就是从0开始，什么东西都从0开始了，所以你不需要为长度跟起始数值还有突然间又有个转置之类烦恼。

周四我遇到一个算是逻辑意外的事件。我要筛选某个表里某一字段不包含某个关键词的记录，但问题是那个字段里的东西有关键词也有空，我需要筛选出来的记录是关键词以外的其它字符以及空的。当我where 字段A not like ‘%关键词%’的时候，结果出乎我的意料。因为那个关键词是包含的关系，所以我没有办法精确控制，所以我必须在关键词的前后加上%。这句筛选的结果是字段里所有那个字段的记录都没有被筛选出来。不就是一个包含的关系吗？Excel的SQL里面允许用正则吗？最终我用的方式是在where里面用两句话，一个是not like，筛选到那个字段里没有关键词，但是有其它字符的记录，另外一个是用or的关系搭配一个isnull(字段A)，这到底是什么情况呢？如果在其他地方，一个contain之类的东西就能表达出来，如果允许用正着，正则也能很好表示不包含关键词，Excel的SQL到底允许我用什么工具呢？

SQL in Excel这把刀到底应该怎么玩？？？

周二中午去吃饭的时候，我突然意识到之前我用VBA+ADO+SQL做跨表查询的时候，把条件参数也当作是一个表。起码在PQ和PP方案里是这样的。在python方案里，我没有把条件参数作为第三个表，我只是直接把数据从Excel的单元格里读取，然后赋值给一个变量，在以后的各种比较之中用。 python的变量相对于VBA来说实在是太自由了，除非是列表元组字典之类要先定义，然后再用，其它都是拿起来就干，不管他什么格式，日期也好，字符串也好，数值也好，都无所谓。之前我之所以没有在VBA+ADO+SQL里把几个日期参数作为变量是因为我不知道如何在字符串形式的SQL里加入变量，正如一开始的时候，我不知道该如何让让下一个SQL用上一个SQL的结果，但现在我已经用得很顺畅了，整个流程下来，我要引用好多遍，有些是引用上一行的，有些是引用好久好久之前的，说白了就是双引号加&加变量加&再加双引号，等于是把变量以外的东西用双引号括起来。所以既然上一个SQL查询可以这么用，为什么我的那些固定参数就不可以这么用呢。显然在VBA里，要把某个工作簿某个工作表的某个单元格数据变成变量实在太简单了。唯一的问题可能是Excel读取那个单元格的数据，那个数据的格式可能跟我料想的不太一样。比如有时Excel觉得那是一个字符串，但有时Excel又觉得那是一个日期，明明某个数据就是一个整数，但是Excel识别出来经过SQL之后直接生成的那个，Excel觉得那个东西是日期。我不知道Excel到底是怎么想的，但是Excel的单元格毕竟不是一个数据库，不像PQ那样，进到PQ里面，如果你得在某些列进行运算处理的话，你就得定义它为你的目标格式而不能让系统默认成为它们觉得的样子。

吃过午饭后我就赶紧去验证我的想法，结果如我所料，那些变量的确能直接通过拼接的方式加到 SQL的查询字符串里，但是拼接的方式又有点出乎我的意料。比如单元格数据读取能识别到那是一个日期，那个变量在本地窗口显示，那就是一个日期，因为那个数据左右是有#的，但问题是当我要把那个数据跟SQL查询里从表获取的其它数据比较的时候怎么比怎么不对劲。之前当我把那个条件参数作为一个表跟其它表的某些字段比较的时候，两个字段我都加了CDate这个公式，也就是我强行把他们可能觉得是字符串的东西转成日期，然后对比。把日期变量放到SQL字符串里连接符都对了，但是就是得不到我想要的结果。在调试过程中我看了一下系统识别到的那个字符串，结果发现虽然那个明明是日期，但是连接上去以后居然就变成了一个不知道该如何称呼的东西。不能说是数值，不是日期也不是字符串，所以我在双引号的之前之后又加了#，让这个四不像的日期在系统的解释之后成为真正的日期，然后再跟其它表的日期字段比较。除了日期变量以外，我的参数还有字符串。字符串变量情况跟日期很相似，所以我做的是在双引号的前后加上单引号。这样的话，经过系统的解释这就是一个一本正经的字符串了。为什么我不在读取单元格数据的时候直接在那个变量前后加#或者单引号呢？因为我发现这般操作跟在写SQL的时候再加#或者单引号相比前者耗时更长。这其中的原理我不懂。

最终，当我的跨表查询从三表变成两表，第三个表的那些内容改成直接赋值以后，整个程序的运行时间马上提升了0.3秒（效率提高30%）。这是一个了了不起的成绩。对老手来说，理论上一开始就应该这么干，我一开始也曾经试过，但当时我实在不知道该如何把字符串拼接上去。

VBA是个很成熟的东西，SQL也是一个很成熟的东西，但是当要在Excel的VBA里玩SQL的时候，可直接借鉴的经验真的少之又少，但这种摸着石头过河的感觉挺好，虽然已经让我到达了某种废寝忘食的程度了。