about SQL, ORM, DSL

SQL, ORM, DSL

语言越高级，可读性就越高。DSL通常用作规则引擎语言，是给非程序员的业务人员使用的。
SQL是一种类似英语的非常友好的 Domain Specific Language。可读性非常高。
是比 python, ruby, Haskell 等解释脚本语言更高级的语言。而这些解释脚本语言是比 OO 语言（如 Java, C# 等）更高级的语言。
对于数据库查询来说，SQL 比 Java API 友好简单许多，所以我一直反对用 Java Query Criteria API 代替 SQL 拼接。
一个很奇怪的现象是，很多人都认为，SQL很低级，不够OO, 不够高级。
也许我们习惯了Java API的OO思维。

Cat cat = CatDAO.findById(…);  /// java api

Select * from cat where id = ?   /// sql

SQL的可读性就这么差? 真是具有讽刺意味。我们的OO教育太成功了。以至于OO程序员很难看懂 给普通业务人员使用的SQL语言。

关系数据库出现之前，其他类型的数据库（网状等）因为模型非常复杂，只用SQL无法表达其中复杂细微的需求。
关系数据库论文中，提出了简单的二维表模型，以至于简单易读的SQL就可以表达几乎所有的数据库需求。虽然关系数据库很慢，由于友好的SQL，后来慢慢成为主流。
EJBQL, HQL, OQL 确实给我们带来了80%简单需求的方便，但是在一些高级需求方面，也带来了不少烦恼。Inner join, outter join, join or not join, fetch or not fetch。在这些地方的具体配置上，又要具有 关系数据库的思维。虽然差强人意，但总有不伦不类之嫌。

多语言无缝集成
.net 的多语言协作的思想。各种适合本域的语言，能够共同使用，彼此之间交织，而能共同合作。所以，DSL, LOP (Language Oriented Programming) 提倡每个领域要有自己的 领域语言。
目前的SQL + Java 的主要问题是，两种语言经常混同于一个文件中，而没有分离出来。(HQL，OQL又何尝不是如此？)
我想，假如一种异类语言不是 嵌入在 其他语言的 源文件中，而是分开的独立的源文件，那么，这是很好的编程模式。也是未来的趋势。
SQL + OO + FP + other DSL….

同意前半部分的观点，关于后面的一句话：

异类语言不是 嵌入在 其他语言的 源文件中，而是分开的独立的源文件，那么，这是很好的编程模式。也是未来的趋势。


我认为需要深入讨论，因为异种语言协作，如何分？如何合？都是很麻烦的问题。

buaawhl，说说你的看法吧。

分的必要性是什么？仅仅是为了优雅？

看着看着就想起了MS的LINQ。
不知道buaawhl怎么看LINQ，
如果sql像LINQ一样在语言上支持，应该不需要了吧。如果要分，怎么分，和MS的partial class有什么样的区别！

分的必要性，主要依据是 DSL 的存在理由。LOP的思路。
某一领域问题，用某一种语言来表达最有效。

比如，
关系数据库查询，SQL 最适合。
Java 的文件对象查询，Java OO API 最适合。
数学公式的处理，FP 最适合。
AOP/Web Service 等场合，解释脚本最适合。（这种情况下，编译语言通常需要 生成另外的code来粘合框架 和 用户代码.）

LinQ 我的感觉是，有些违背Domain Specific，试图用 类SQL 描述所有领域。


"异种语言协作，如何分？如何合？都是很麻烦的问题。"
确实如此。比如，Java OO 和 RDB 的合作。
ORM 就是 SQL 和 OO 之间的桥梁。同时也引入了不少麻烦。
如查询条件。本来 where a = ? and b = ? .... 这应该划分为 Java OO Critea API 领域，还是 SQL 领域？
我的看法是，划分到 SQL 领域。因为觉得

where a = ? and b = ?

的可读性比

new And( new Equals("a", a),  new Equals("b", b) ) 的可读性要高。

但是这种情况下，相互干涉的情况，几乎无法解开。不可能分的那么清晰。总有一个领域，要侵入另一个领域。我们只能让这种侵入变得更少，变得更合理。
至于合理的标准，也很难确定。我的主要依据是 可读性。哪种划分方法，带来的整体可读性 更好，可读性损失最少。
比如，动态条件拼装，有如下几种方式

1.  SQL 嵌入到 Java
if( a != null ) sql += " a =  " + a;
if( b != null ) sql += " b =  " + b;

2. Java API Critea ... 一种语言领域的入侵，用Java OO 表述 SQL领域的工作

if( a != null ) critea.add( new Equals("a", a) );
if( b != null ) critea.add( new Equals("b", b) );

3.  SQL template ... 拼装Logic 嵌入到 SQL中

// BEGIN DYNAMIC : a
and a = {a}
// END DYNAMIC : a

// BEGIN DYNAMIC : b
and b = {b}
// END DYNAMIC : b

-----------------
上述三种做法中，我比较倾向于第三种，因为我觉得，这样带来的 可读性损失 最小。

我是比较喜欢sql,如果是处理查询为主的业务的话.

"虽然关系数据库很慢，由于友好的SQL，后来慢慢成为主流。"
这个话不对,数据库慢是因为磁盘慢.
总体来说,在所有的存储技术中,关系数据库性能是最好的.

要说有些银行他们为什么不用,那是因为历史原因不是技术原因.

sql最大问题是处理嵌套,循环及递归非常不便.

一般的做法都是用sql把一定范围的结果集读到内存,用普通程序语言进行后续处理.阻抗由此产生.

SQL强于数据存取,弱于计算.


对于这样的情况,数据库厂商都对sql进行了扩展,虽然解决了一些问题,但也带来了专有产品特性绑定.象oracle的p/l sql就是很强的.可以说是混入了异种语言的sql
以前那个sqlj,好象就是oracle领头搞的吧,可惜没成功.我在学校时,曾是java存取标准的候选人之一,呵呵

ORM最适合的场合是OLTP,其实也就是数据输入.真的要查询,简单的用用也很好,复杂的报表之类,还是直接用sql好.

我喜欢第一种,但不直接在java中拼装完整的SQL,而是用先用数据库的专用特性(怎么方便怎么用)形成合适视图,这样需要拼接的SQL就比较直观,处理起来也没那么麻烦.

第3种我喜欢，php的template风格！呵呵！
不过这样的话需要一个template engine来处理。

我理解你的这个sql template是一个独立于java文件外的。那么运行方式是否类似iBatis？

Yes.
iBatis, OR Broker之类，都采用了各种各样的 SQL template Engine.
iBatis 采用 XML.  OR Broker 采用 velocity. 我采用fastm.

看起来，fastm更干净一些。仿佛没有逻辑，只描述结构。而 ibatis xml, velocity 等方式都有明显的 equals, if, else 等逻辑。感觉上，属于java 等编程语言的逻辑，侵入了 SQL domain.  fastm 更象划分条件块的注释。

恩恩，orm是不适合处理OLAP的。如果处理OLAP的话，复杂性太高，效果还不好！

看来你的那个开源项目做的差不多了！嘻嘻！公布出来让大伙开开眼。