欢迎来到Doc100.Net免费学习资源知识分享平台!
您的位置:首页 > 程序异常 >

关于抽象查询语言的构思,该如何处理

更新时间: 2014-01-05 02:30:57 责任编辑: Author_N1

 

关于抽象查询语言的构思
大家都知道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,也不知道这方面是不是有现成的作品,相关的标准和研究?总之我是没找到,不知道大家有没有兴趣,有什么建议和想法?


--参考方法--
楼主一下子研究这么高深的东西,让我们这些笨笨如何能跟得上技术的进步啊。

帮顶一下 。
--参考方法--
顶..........
--参考方法--
顶..........
上一篇:上一篇
下一篇:下一篇

 

随机推荐程序问答结果

 

 

如对文章有任何疑问请提交到问题反馈,或者您对内容不满意,请您反馈给我们DOC100.NET论坛发贴求解。
DOC100.NET资源网,机器学习分类整理更新日期::2014-01-05 02:30:57
如需转载,请注明文章出处和来源网址:http://www.doc100.net/bugs/t/10794/
本文WWW.DOC100.NET DOC100.NET版权所有。