无论程序员，还是数据分析师或科研工作者，有很多人都会编写SQL。无论单机上的access，还是局域网中的mysql或云环境中的Hadoop，也有很多平台都支持SQL。经过半个多世纪的演化，SQL已是应用广、成熟度高、使用方便的数据查询语言。
但有时候数据在CSV/TSV/XLS之类的文件里，为了能继续使用熟悉的SQL，我们不得不先把文件导入数据库。这个过程很麻烦，要建立表结构、设定字段名和数据类型、分配权限，再等待加载。如果涉及多个文件导入，这个过程就会变成更为耗时耗力的重复劳动。文件越多体积越大，还要应对表空间不足的问题。有些文件经常更新变化，就不得不反复导入，这都令人难以忍受。
更麻烦的是，还有些文件就不能导入数据库，或者勉强导入也没法用，还不如用Python或JAVA等开发语言直接计算。常见的情况有：开头或结尾的数据无用、分隔符不规范（不可见字符、双字符）、文本格式不规范。比如一行对应多条记录的情况：
此外，大部分数据库都不支持导入xlsx，需要安装Excel或第三方工具。安装Excel的话，需要将xlsx转为csv再导入数据库，烦；用第三方工具直接导入的话，环境配置复杂，有的只支持xls，有的只支持低版本的xlsx，更烦。
总之，文件入库是个麻烦不断的过程。
那么，有没有能直接针对文件执行SQL的工具？
可以想象，如果能在文件上直接执行SQL，就能避开入库带来的一切麻烦，大大提高工作效率。由此还能带来更大的好处：再也不必为了计算文件，而专门部署和维护一套数据库系统。
优点如此显著，工具自然不缺。
但先别高兴太早。号称能直接针对文件执行SQL的工具，或多或少都会存在一些缺陷，有些缺陷还很致命。下面，让我们先从最轻便的命令行工具开始，深挖一下各类工具的真实能力。
csvsql
既然是命令行工具，csvsql必然具备短小快捷的优点，比如带列名的sales.csv文件，按client列分组，对每组的amount列求和，只需在命令行简单写一句：
遗憾的是，csvsql除了体积小、编写SQL快捷之外，就只剩缺点了，其中最大的缺点是安装配置复杂。csvsql本质上不是独立程序，而是个Python脚本，所以必须事先配置好Python环境，又因为许多功能依赖第三方，所以还要下载合适版本的函数库。这些对程序员来说还算容易，但对数据分析师来说，就有点太为难了。
csvsql的第二大缺点是没有自己的计算引擎。csvsql内置了一个SQLite数据库，当我们敲完SQL后，csvsql先以IN-MEMORY模式启动SQLite，然后默默建表，并将文件全部加载到SQLite，接着把针对文件的SQL翻译成针对数据库表的SQL，再执行翻译后的SQL。
没有自己的计算引擎，首先会导致SQL能力不足。csvsql必须根据SQLite的语法设计一套自己的SQL，还要将针对文件的SQL翻译成针对库表的SQL，没有强大的技术实力，自己设计的SQL就会趋于保守，翻译的过程也很难面面俱到，所以csvsql丢失了很多基本功能，比如模糊查询和日期函数，而这些功能SQLite原本是支持的。
没有自己的计算引擎，还导致计算性能不足、文件体积受限。每次执行SQL时，csvsql并非直接对文件计算，而是多了一步导入内存的过程，加上类型转换，耗费的时间会相当可观，因此计算性能较差。文件从硬盘到内存后，体积会变大很多，如果文件较大而机器内存较小，不仅加载时间漫长，还可能发生内存溢出，所以文件不能太大。
归根到底，上面两大缺点是因为技术实力不行，所以，下面更多的缺点就不难理解了。
第三点：只支持文本文件，不支持日常工作中很常见的Excel。
第四点：对文本格式要求太严。csvsql只能读取最基本的CSV格式，如果要实现定义分隔符、跳过无用行、区分首行列名等常用功能，就只能借助其它文本编辑工具进行预处理。如果开头或结尾的数据无用、分隔符不规范（不可见字符、双字符）、文本格式不规范，则须借助Python、JAVA等开发语言进行预处理。
类似csvsql的命令行工具还有不少，比如textql、querycsv.py、q，这些工具虽然略有差异，但因为基本原理类似，所以上面的缺点一个都不少。
虽然命令行工具都没有自己的计算引擎，但有一类工具一定有，那就是数据库系统。下面让我们看看HSQLDB，一款相当常见、且能直接针对文件执行SQL的数据库系统。
HSQLDB
数据库本身就是技术实力的表现，所以HSQLDB不仅有自己的计算引擎，还提供了强大的SQL语法，无论关联查询、子查询，还是模糊查询、日期函数，HSQLDB一个都不少，这一点是命令行工具无法比拟的。
但安装、管理、维护数据库是一件很麻烦的事，尤其是维护，我们不仅要分配权限、硬盘、内存、缓存，还要配置各种各样的复杂参数，这些工作对数据分析师来说相当困难。事实上，我们之所以希望在文件上直接执行SQL，很重要的一个原因就是为了避开数据库的维护。
不仅日常的维护和管理麻烦，在文件上执行SQL时，操作步骤仍然复杂。
启动HSQLDB的服务器和客户端（也可用第三方客户端工具比如SQuirreLSQL）的命令格式就很复杂
这东西，不熟悉java的非专业程序员都会望而生畏。
客户端连接服务器的参数配置也很复杂：
还要执行多条预处理语句，包括删除可能存在的表名、新建表结构、将文件对应到表，才能真正执行SQL。其中，将文件对应到数据库表时，需配置大量参数，如下：
除了操作过程复杂，HSQLDB还有很多不合理之处。HSQL不支持自动解析数据类型，把这个麻烦扔给了用户，让用户自己建表结构。为了方便使用，很多文件的首行都是字段名，尤其是csv，但HSQLDB要求用户建表结构并指定字段名，这就导致文件首行的字段名完全无用。我们的启动方式明明是server而不是in-memory，但HSQLDB却会把文件事先缓存到内存，这就会影响整体性能，尤其是文件较大时。
可以看到，HSQLDB虽然有自己的计算引擎，但底层核心仍然是数据库表，并非真正的文件计算引擎，所以才会出现诸多不合理之处。由于缺乏真正的文件计算引擎，所以HSQLDB不支持Excel，不支持常见的文本格式，更不支持不规范的文本格式等等。
与HSQLDB类似，H2database和PostgreSQL也可以针对文件执行SQL，操作过程虽然迥异，但基本原理没大区别，所以优点缺点如出一辙，这里不再赘述。
数据库缺乏真正的文件计算引擎，而且从安装管理到配置执行都很复杂，那有没有既有文件计算引擎，还有友好的交互界面，可大幅降低使用难度的桌面工具呢？还真有，下面会讲到。
OpenOfficeBase
作为桌面工具，OpenOfficeBase的易用性令人印象深刻：一键安装，即安即用无须配置；界面友好，操作快捷交互流畅。
不仅外表易用，OpenOfficeBase的内核也很强大，因为它有真正的文件计算引擎，可以对文件直接计算，而不必将文件加载到其他数据库，也不必用数据库引擎计算文件。这就带来了三个明显的改进：自动识别文件中的数据类型，可计算超过内存的大文件，整体性能大幅提高。
可惜的是，这个文件计算引擎并不完善。
第一，OpenOfficeBase只支持文本文件，不支持日常工作中很常用的Excel，这就大大限制了使用场景。
第二，OpenOfficeBase的SQL能力极为有限，很多基本功能无法实现，比如下面的关联查询：
第三，对文本格式限制过多。
除了默认格式，不支持任何其他格式的数据类型，比如下面特殊格式的日期：
不支持特殊分隔符，比如下面的格式：
复杂情况就更不能处理了，比如下面的格式：
如果对格式标准的文本文件进行最基本的查询，OpenOfficeBase是首选工具，但实际工作和理想环境不同。在实际工作中，我们会经常遇到Excel，文本格式总是各式各样，SQL算法也应自由灵活。如何才能在实际工作中对文件执行SQL呢？那当然是文件计算引擎较为完善的工具了，准确地说，是下面要讲到的编程语言集成组件。
Microsofttext/xlsdriver
作为实力大厂出品的编程语言集成组件，Microsofttext/xlsdriver几乎无所不能。在SQL语法方面，该组件不仅支持模糊查询、日期函数，也支持子查询和关联查询，基本覆盖实际工作所能遇到的各种算法。比如关联两个csv文件：
文件类型方面，该组件不仅支持TXT/CVS/TVS，也支持XLS/XLSX，而且没有版本限制，这一点在实际工作中非常便利。
对于常见的文本格式，该组件支持得非常好，比如定义分隔符、区分首行列名、设置固定宽度的列、自动识别数据类型。对于复杂的文本格式，该组件虽然不能直接处理，但能通过编程间接计算。理论上来说，程序员可用该组件读取任何文本格式，可实现任意业务算法。
Microsofttext/xlsdriver的文件计算引擎较为完善，从能力上来说缺陷很少，但它是程序员的专业工具，并不适合数据分析师。
第一，该组件的技术门槛很高，要想正常使用，必须掌握一门编程语言，比如C#或VB。在熟悉编程语言的基础上，还需要学会ODBC、OLEDB、ADO这三种具体的编程接口之一。
第二，该组件需要编写大量难懂的代码，才能真正执行上面的提到的SQL语句。简化后代码如下：
第三，该组件扩展困难。上面的代码只能适用于最规范的文本文件，如果要定义字符串格式或数据类型，还需使用schema.ini配置文件。如果要解析复杂的文本格式，还需额外编写大量代码。
除此之外，Microsofttext/xlsdriver还存在一个问题：textdriver和xlsdrvier虽然用法类似，却是两个独立的组件。换句话说，文本文件和Excel之间不能进行关联计算，除非额外编写大量代码。
与Microsofttext/xlsdriver类似，CSVJDBC/ExcelJDBC、SpatiaLite也是支持在文件上直接执行SQL的编程语言集成组件，虽然语言环境不同，但基本原理类似，所以使用难度都很高。而且这两种组件不是实力大厂的产品，比起Microsofttext/xlsdriver要差上不少。
Microsofttext/xlsdriver的文件计算引擎虽然完善，但使用难度很高。OpenOfficeBase易用，但文件计算引擎不够完善。那有没有兼具二者优点，适合数据分析师使用的工具呢？要求苛刻，中者寥寥，目前只发现下面这么一款产品。
esProc
与OpenOfficeBase类似，esProc是易用的桌面型工具，一键安装无需配置。比OpenOffice更易用的是，esProc可以在单元格直接编写多条SQL，计算结果和SQL直接呈现在同一界面，点击SQL所在的单元格可切换观察计算结果。
与Microsofttext/xlsdriver类似，esProc具有完善的计算引擎，可支持实际工作所能遇到的各种SQL语法（见上图），这是OpenOfficeBase做不到的。
文件类型方面，esProc支持TXT/CVS/TVS，也支持不同版本的XLS/XLSX。比Microsofttext/xlsdriver更强大的是，esProc可以直接对文本文件和Excel进行关联计算（见上图）。
除了规范的文件格式外，esProc还可以利用扩展函数应用更复杂的情况。比如分隔符为
的文件，OpenOfficeBase无法解析，Microsofttext/xlsdriver要编写大量代码，而esProc只需在SQL中使用扩展函数：
esProc可自动识别数据类型，对于非默认格式的数据，比如前面提到的特殊日期，OpenOfficeBase无法解析，Microsofttext/xlsdriver需用schema.ini配合代码实现，而esProc只要使用简单的扩展函数就能轻松应对：
格式复杂的文本，比如前面提到的一行文本对应多条记录的情况，OpenOfficeBase无法解析，Microsofttext/xlsdriver需资深程序员编写大量复杂代码，而使用扩展函数后esProc也不难处理：
分析过十几种工具之后，我们可以得出最终结论：号称支持文件上直接执行SQL的工具中，绝大多数只是徒有其表，真正可用的其实只有Microsofttext/xlsdriver和esProc，前者只适合程序员，后者才适合数据分析师。