我的天

花了两天时间，又做了另外一个PQ的跨文件查询。这一次思路我感觉相对比较简单。某一个大表基本已经满足了所有需求，唯一需要查询的是某个类别的合同号，另外一个类别的合同号在大表里已经有，所以需要做的只是研究该怎么分组。分组这个东西也是个学问。东西一旦分组就可以节省很多，然后你再把大表里面的列删减到你需要的范围，又能节省很多。这些东西节省下来必定意味着效率提高，最后我只把最终的版本输出，其它脚手架查询仅限连接。删除列有两种方式，一个是直接删除，另外一个是在分组的时候直接不理睬，这就意味着分组出来以后那些不被理睬的列被删除了。

一开始之所以想做这个跨文件查询，是因为很早很早以前，准确来说大概是2017年的时候我就考虑过应该用什么方式把客户跟数量，再把同一天的多个客户数量连接起来。这个东西思路简单，但以我当时的知识是没办法做到的。我现在用PQ、PP或者python都可以实现。首先是让客户数量已经称量单位无缝连接，接着是把一天内多个客户数量通过分组结合在一起。我觉得PQ的分组挺奇怪。文本没有给出聚合的方式，但实际上通过生成代码后修改公式，实际上可以把文本聚合，为啥就是不让可视化一步到位呢？？？同样，明明某些数字是可以用计数的方式表达出来，但是聚合的界面就只有行计数，对某些列来说那又是不可选的，但实际上同样先选择sum或者average生成代码以后，把那个东西改为count就能实现功能，没有任何问题，所以为什么在可视化生成的时候，就是不给我这样的选择呢？分组这个东西本来是很自由很牛逼的，但我估计很多人会被PQ这种阉割的可视化逼退，觉得可能那样做不到。

在这两天的研究中，有两个东西耗费了我比较多时间。一个是有时间区间的查询，比如说一段时间之内是第一个合同号，另外一个时间段是另外一个合同号。这就意味着你要查询某天对应的合同号，首先你得先知道某天是落在了哪个时间范围之内，然后在找到相应的合同号。有人在知乎上说这样的解题思路是先对那些一段时间内的合同号生成一段连续的日期，然后再对需要索引的时间以及合同号做日期以及客户的索引。这样的思路没有问题，但是这太劳民伤财了吧。如果需要被用作索引的合同号很多，那得浪费很多连续日期做索引。直接的解题思路应该是先以客户单因素做合并查询。查询的结果将是一批时间段和合同号，然后用新增列的方式再次定位需要索引出合同号的日期的时间段。筛选的结果将是一个列表，最后只需要把列表深化出来。需要注意的是深化出来的列表可能包含不只一个合同号，这样就需要做文本聚合。每次说到深化，PQ总会有两个可视化的选项，一个人是直接列出结果，另外一个是聚合，但是聚合的那个地方除非是数字，否则就只有计数，但实际上跟之前的分组一样，完全可以把文本用分隔符连接起来。

第二个让我耗的比较多时间的是怎么替换某一列的多个内容，而不需要先建立一个条件列，然后删除原列，最后再改条件列的名称为原列名称。这样的思路一点问题都没有，但是既然我可以在原列上修改，为什么我要这么折腾分三步呢？要说到这个就得好好研究用作替换的那个公式。玩好了替换的公式可以自己列的内容自己换、其它列的内容决定自己列怎么换，也可以换一遍又一遍嵌套着换。

上周折腾PQ主要是以实现功能为主，这一次除了实现功能以外，我也对代码进行了整理，比如最大程度简化代码，把步骤的名称变得更人性化等等。

两天的时间就把一天到晚都得做的事情直接规范化了，虽然这其中的某些细节还是无法做到，但起码那是极少数的特例，所以两天的努力，我感觉已经解脱了95%以上的日常工作。