续：我们需不需要像存储过程一样的跨数据库的JA
（原：我们需不需要像存储过程一样的跨数据库的JAVA存储过程）
接触过数据库的同学肯定知道存储过程，先列一下好处?
1：易于调试。
2：随时可以查看其原代码。
3：便于测试及跟踪。
4：性能良好。
缺点：
1：只能用于特定的数据库。
2：保密性不强。
3：语言单一。

以下是一些简单说明，如果我们开发出一款类似于存储过程的"Java存储过程"，他有存储过程的好处，又可以克服存储过程的缺点，你会用吗????

经过这段时间的讨论以及对技术的调研,总结如下：
1、SQLJ：这个确实是好东西，与我的想法基本一致，也试用了一下。可以在数据库上用JAVA写储储过程，是基于JDBC上的封装，目前只看到Oracle与DB2有解析，开发工具也是这两家独有的，第三方的开发工具基本没有（可能我没找到），还有解析器也没有开源的，用到j2ee服务器上会不会有法律问题，这个没有深入了解。还有SQL语句是在标准的基础上加了一些扩展，不能做到跨数据库，与传统的存储过程对比，移植方面会更好。很可惜的是不能成为Java的一项标准，否则现在的Hibernate应该就不会这么火了。
2、JSQLParser:SQL的语法解析器，这玩意儿也不错，可以校验SQL语句，或许能够派上用处。
3、LINQ to SQL:微软的玩意儿，这个还是相当的好的，功能强大，在Java方面只有Linq，LINQ to SQL还没见着，可惜了。
4、自已写一个解析器，这个可行性还是很高的，而且现有有很多文法解析框架，实现起来应该不难，关键是还得有配套的开发工具，这个是个大工程，短期内很难实现，而且价值不高。
5、使用模板引擎结合JSQLParser来实现，这个可行性还是很高的，但看着模板引擎的语法怎么看怎么不舒服。
6、利用注释+Java语法+JSQLParser作为扩展脚本来实现(非常怪异、应该没看懂)。简单上说就是在java的注释里写sql脚本。如下：
/**
SQL{
--这是一个获是用户的sql语句。(对sql的备注)
select * from users where a.user = 'super';
--这个太普通了，再来一句有深度的。
  select user_code to ${userBean.user_code},user_name to ${userBean.user_name} from a.user = 'super';
}
*/
这个类的扩展名不是java叫sqld(SQL帝).将sqld根据简单的规则转换成java源码(SQLJ的原理一致),写在注释也有好处，生成的java doc里，就有业务逻辑，以后查小问题你就不用看代码了。或者这样说，哪些蛋疼的问题就让客服和工程去忙去吧。
当然，这么干的话很多开发人员会拍砖。
所以、数风流人物还看今朝。看各位了.........