关于抽象查询语言的构思

谢继雷 2009-03-09 03:59:29

大家都知道SQL，SQL有很多分支，不同数据库系统实现不同，使用的SQL也略有差异。有最基本的SQL标准如SQL89,SQL99,SQL2003等等，下面是一个简单的小结：

　　1974-79： IBM 以Codd的理论为基础开发了“Sequel”,并重命名为"SQL"；
　　1979： Oracle 发布了商业版SQL
　　1981-84：出现了其他商业版本，分别来自 IBM(DB2),Data General(DG/SQL),Relational Technology(INGRES)；
　　SQL/86：ANSI 跟 ISO的第一个标准；
　　SQL/89：增加了引用完整性(referential integrity)；
　　SQL/92(aka SQL2)：被数据库管理系统（DBMS）生产商广发接受；
　　1997+：成为动态网站(Dynamic web content)的后台支持；
　　SQL/99：Core level跟其他8种相应的level，包括递归查询，程序跟流程控制，基本的对象（object）支持包括oids；
　　SQL/2003：包含了XML相关内容,自动生成列值(column values)；
　　2005-09-30：“Data is the next generation inside...SQL is the new HTML”! Tim O'eilly提出了Web 2.0理念，称数据将是核心，SQL将成为“新的
　　HTML"；
　　SQL/2006：定义了SQL与XML(包含XQuery)的关联应用；
　　2006：Sun公司将以SQL基础的数据库管理系统嵌入Java V6

而有些不在标准之内的，但又是非常有用的，比如MySQL的SHOW TABLES，比如Oracle的虚拟的DUAL表（该表只有一行，但没有任何列，用于简单计算例如 SELECT 表达式 FROM DUAL）。

我的想法是，是不是可以设计一个抽象的查询模型，通过编译程序将这个模型编译到各种不同的数据库系统中去。有点像 Hibernate HQL 所做的，但HQL编译是发生在运行时的，而且HQL本身是一个脚本语言需要通过词法/语法分析器将其转换到抽象语法树，再对语法书进行优化什么的，再生成具体的SQL语言实例。我的想法是将这个编译动作放在先前执行，（当然根据需要也可以运行时再作决定）编译的结果并不是SQL实例而是计算机内部表示的求值树（evaluation tree），当求值这棵树的时候将它表达为具体的SQL实例。

这样做的好处是，程序可以不必书写难看的夹有一大堆引号的字符，当然PreparedStatement可以将引号改成问号，但我也不想要一大堆莫名其妙的问号。当然你可能会说不用问号也行，最近LINQ还是什么的开始支持Named-Parameter了，把每个问号起一个别名，再通过别名把参数值传递进去，但我也不想要别名！

举一个形象的例子：
select * from dogs where color='red'
最开始是这样的：
"select * from dogs where color='" + color + "'"
这样可能会产生SQL注入漏洞，所以变成：
"select * from dogs where color='" + escape(color) + "'"
为了更好看，于是演变为：
psql = "select * from dogs where color=?"
psql.setParameter(1, color)
又引入参数别名：
高级psql = "select * from dogs where color=<color=?>" （类似物）
psql.setParameter("color", color)

但自始至终也没有摆脱《字符串》的束缚，你怎么看都是一个《乱》，这样的字符串让你感觉你写的东西就像垃圾，它既不能通过编译找错，也不可能在其中加入任何可能的优化，所有的优化都要延期到发送给数据库服务器后台了才有可能发生。

不知道你们有没有用过perl的html模型，最早的CGI程序有很多用perl写的，那个时候就有函数式编程味道的cgi程序，样子大概如：
HTML(
HEAD(TITLE("Hello, World")),
BODY(H1(P("This is my first cgi program")))
)
我想引用这个例子来说明，我们也可以构造一个类似的SQL抽象模型，如
sqlmodel = SELECT('*',
FROM("dogs"),
WHERE(EQ("color"), color))

SQL可能会很复杂，相应构造出来的sql model也会很复杂，比如会有很多嵌套查询和交叉表关联，根据不同数据库可能还会有很多调节因子，例如Oracle的写在注释里的性能调优指令（真他妈烦人，Oracle见鬼去吧！）例如跟他妈变色龙一样复杂多变的自动编号字段，还有他妈各种各样淫荡的分页方式，我想说的是你永远别想写出一个漂亮的通用的数据库应用程序，回到这段文字的开头，SQL可能会很复杂，当SQL变得复杂了之后，你肯定要问那么sql-model将怎么引入优化？如果是直接写sql，我就可以针对具体的比如说oracle作专门的优化，如果改成了这种sql-model我就做不了优化了，是不是这样？我觉得第一，也就是18个月计算能力翻一翻的那个什么破规律，会使一些不必要的优化技术（不涉及本质的，只能稍微提高一点点速度的那种优化）就别去弄它么好了，第二，用sql-model生成出来的具体的SQL语句，接下来还是要送到数据库后台去处理的，也就是说，它《仍然会被进一步优化》，所以，与其把字符串SQL搞得那么复杂凌乱，我们是不是更应该设计漂亮的结构化的sql-model？第三，如果sql-model是比SQL更优秀的，也就是如果大家都认为sql-model应该取代sql字符串，那么是不是将来的DBMS会根据我们的sql-model而演进，而更适应于使用sql-model的方法？

我刚查了google，也不知道这方面是不是有现成的作品，相关的标准和研究？总之我是没找到，不知道大家有没有兴趣，有什么建议和想法？

...全文