我的天

周四的傍晚时分，我突然有点码农蓝调的感觉，因为好像无论我怎么整，前面总有无数的奇奇怪怪的问题。这些问题居然没有大路的答案。原因是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这把刀到底应该怎么玩？？？

数据本身没有问题，如果我们不能让它们确立某种关系，只是因为我们对那个东西还不够了解而已。在Excel里做一件事，你可以通过很多方法，比如说函数，比如说VBA，比如说SQL查询，又或者Power Query或Power Pivot。当然，我这里所说的，主要是针对查询，或者说数据清洗类的东西。如果纯粹是针对单元格的格式化，函数以及Power BI系列以及SQL是没办法做到的。

同样一个数据，用不同的方法都可以得出目标答案，但是哪个会更简便快捷一些呢？函数我觉得挺被动的，尤其是在处理大量数据的时候，效率非常低。因为在处理一些复杂东西的时候通常要用到数组函数，即便不需要用到数据函数本身，其实也在运用着数组函数的变体。而且函数这种东西受Excel本身版本的限制，越是低版本的Excel越是没办法轻而易举地实现某些逼格的功能。于是就出现了你不得不为了某个功能升级Excel，又或者因为你的伙伴升级了Excel，用了一些高端的函数，但是你却看不到，工作就没办法继续下去了。SQL和VBA是两个大杀器，很早以前Excel就已经支持。与其说他们是Office软件的一部分，不如说这两个东西更接近于编程语言。我对Excel里面的SQL不是十分熟悉，因为至今为止，虽然已经折腾了不少网站，但是我从未试过操作数据库。SQL在Excel可以用，但我觉得可能在Access里SQL会用得更顺手一些。比如说如果改变数据源，比如移动文件之后，SQL需要重新连接。若没有VBA的帮助，这是无解的。我不喜欢用SQL的其中一个原因是它会在硬盘的某个位置生成某个数据库。

VBA这个东西强大到任何你想到想不到的东西都可以控制，无论是数据本身还是说单元格的格式，一律通杀，它甚至可以让Excel自杀，又或者让你的系统自杀。VBA用得好不好直接决定了某个脚本的运行效率。是对初级用户来说，VBA的学习成本实在是高，除非你从来不打算要建立自己的规则而纯粹只是用别人的东西。

至于Power BI系列的Power Query和Power Pivot现在我仍然处在甚至还不能说入门的阶段，我只是稍微了解了一点这两个东西。在数据清洗和建立关系的时候，它们实在太强大了。但是要使用这两个东西，Excel的版本就必须有要求。所以这也导致了不少免费用户直接绕过这两个强大的东西。我也不知道为什么自己在使用Excel高级函数几乎还没入门的情况下，我就去折腾M语言。我觉得那个东西一定程度上颠覆了我对数据的理解。Power Query对数据的处理方式就像通过各种蹂躏就能得出你想要的东西，其间你没有修改原数据，所以实际上在写M语言的时候就像是手工编写一个宏，而那个宏要比一般的VBA简洁很多。之所以简洁，一定程度是因为那是在高级套用的前提下。Power Query里玩的数据转换实际上是在折叠、删除以及扩充，一定程度上就像是在用类似于递归或者迭代的方式。

别人把时间耗在应付考试上，我把时间耗在折腾自己上。

还记得初中的时候数学老师跟我说初等数学比高等数学难多了，幸好，我这辈子暂时只学过高等数学，而且几乎都还给大学老师了……

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# def first(word):
#     return word[0]
# def last(word):
#     return word[-1]
# def middle(word):
#     return word[1:-1]
# def is_palindrome(word):
#     if len(word) <= 1:
#         return True
#     elif first(word) != last(word):
#         return False
#     else:
#         return is_palindrome(middle(word))
def is_palindrome(word):
    return word[::-1] == word
word = input('word is ')
print(is_palindrome(word))
# word is qwerreq
# False
# word is poiuuiop
# True

大学学习C语言的时候，基本上我不会写单独的函数，所有要解决的事都在主函数里搞定了。当时我学过判断和循环，但是，我却从来没学过递归。在解决一些简单事情的时候，循环跟递归，没什么差别。从理解程度来说，我觉得循环更简洁一些，但是，当某个东西像套娃那样一层叠一层，每层里面依然用同样的规则继续套叠，不知道要叠多少层的时候。递归就会展现它无穷的魔力。循环难以实现这个，又或者循环并非实现不了，但是递归在完全不需要体现循环的框架下，简洁的语言就已经在做着循环的事情。

昨天，我第一次在Python里见到这个恐怖的递归。外国人的书，我觉得都有一个特点。正文的时候举的例子都很简单，但是一到习题，就会把你彻底搞死。习题里面会偷偷带入一些超纲的东西。大概写书的人理所当然默认你应该知晓。这种事情我已经在学习Java的时候领略过。当时那本书之所以没法看下去，就是因为我没办法想象出作者的脑洞到底是什么。他们的习题几乎可以说大多是一些填空题，但要实现一个功能，其实未必一定就得用某种方法。你给我一个条件，给我一些目标值，我能做出来也就OK了，为啥必须走你的路呢，这非常难。之前我不觉得自己跟外国人的脑洞到底差多远，但是当我对比过自己和他们写的程序以后，我发现真的差挺远的。虽然我们都能实现某个功能，就效率而言，感觉上没差多少，因为我只是在做一些非常初级的东西。应试教育的时候，有标准答案，当然好判定成绩，但实际上，编程这种东西真心应该天马行空。给我一个效率的限制，比如说完成某件事，必须在多长时间之内解决，代码长度不能多于多少，至于我用什么办法，这是我的事。

说回递归函数这件事，在处理几个简单数字的时候，可能你感觉不到它的强大，但是，当我见识过用那个东西画出来的层级图形以后，我简直就只有站在旁边瑟瑟发抖的份儿。真的不知道是哪个神经质想出来这么强大的东西。但实际上，深究下去，那也不是很强大，那不过是不断地重复一些已经设计好的事情而已。如果要人去做那些重复，一开始还好，但是随着事情的深入，会慢慢乱套，但是计算机不会，他们会一根筋地执行我们的指令。最终出来的结果是令人惊叹的优雅，还是乱七八糟一坨屎：就得看设定规律的人的功力了。

递归现在对我来说是一个非常恐怖的东西。因为我不了解它，所以我害怕它，就像当年认识循环一样。但是，用好递归以后，我的武器库里就会增加一个杀伤性非常大的家伙。说到递归，让我联想起新冠病毒。这个东西的递归到底什么时候才是个头？我觉得这肯定不是一个死循环，自然界非常擅长递归，处处都是数学和逻辑你知道吗？！但是，到底要递归多少次，全人类才最终能看到隧道尽头的曙光呢？到底这个新冠病毒函数的递归里埋伏了多少个随机数呢？学习递归让我明白到，层级少好对付，层级一旦扩增，那就是次数级的增长，而且，说不准到达一定层级的以后就会触发某些大招炸弹，想想都心寒。

编程是一个让我重新理解自然规律的过程。

先画一个正方形，然后画一个正多边形，接着画一个圆形，最后画一个圆弧。从思路上说，再简单不过了，但实际上实施起来的时候，我还是花费了一点心思，但这些东西跟之后的用圆弧画出三个花朵比起来，我算是轻而易举就完成了的任务。后来的花朵之所以耗费了好几个小时才终于搞定，倒不是因为问题本身有多难，而是因为其实我没想通那些数学上的问题。我要画一朵花，花是由花瓣组成的。我画的那朵花是规则结构。那么画完一个花瓣到下一个花瓣的时候，角度我应该如何确定呢？这个问题很简单，但实际上我却在这里兜了无数个圈。我在那里瞎猜，所以很浪费时间。有无数次，我想直接去看答案了，但是我还是控制住了自己。当我终于画出一朵花，并在里面测试无论花瓣是胖是瘦，是多是少，我都能画出来以后，接下来我考虑的是如何一次性在一个面板上画出三朵花。画出一朵跟一次性画出三朵，其实已经非常接近了，但要怎么实现，还是费了一点心，因为某些函数的应用书上根本没说。我去网上稍微搜了一下，发现直接搬过来，而且是在没有看到例子的时候就搬过来行不通。最终我用了COPY大法，一次性画出了三朵花，虽然花的大小跟要求的有点差别。当我看过答案以后，我觉得这种差别是完全可以理解的。胖瘦跟大小是由他们设定的参数决定的，那些参数我们不可能知道。我只能模拟出个大概比例，要我完全模拟出一模一样是不可能的。

小海龟这个东西是一个画图的玩意，但是那又不像艺术家手里的画笔那样随心所欲。那是编程出来的，编程出来的东西还是有大神可以画出个小猪佩奇，但这些做法正如某些大神能用Excel的单元格画出他们想画的任意东西一样。

玩过成年人常规的编程以后再去搞这个小海龟，我觉得最难的地方在于数据的运用。你该怎么处理那些数据？难就难在那些公式设计上面。我不知道为什么Think Python 2这一章要这么整人，但也正是因为他们把我整得很惨，所以我在函数调用上面的确有了一些思路，而那种感觉是从前老师又或者我自学的课程里从来没接触过的。这些才是最核心的东西！为了让我懂得这个，他们祭出了从来都让我很崩溃的小海龟。

现在回想起来，为什么小学的时候小海龟会那么容易让我崩溃，估计情况跟现在差不多。在解决问题的时候我没有把那个箭头当作是一条数学题，一定程度上我把它当作是一个游戏了，所以当我不可以一口说出答案的时候，我首先开始做的是瞎掰，折腾好长时间以后我才终于静下心来，用脑子去考虑，这到底是怎么回事。所以可能某些东西的实现并不难，但是因为我耗在瞎掰上面的时间太多了，简直把我搞得慌张了，所以我会对那个东西瑟瑟发抖。把大问题解剖下来变成小问题，再逐个击破，我应该能很快的发现我的问题所在。

战胜人生中曾经不敢去面对的，非常有意思。