整理：小弟我们需不需要像存储过程一样的跨数据库过程
日期：2014-05-16 浏览次数：20463 次
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里，就有业务逻辑，以后查小问题你就不用看代码了。或者这样说，哪些蛋疼的问题就让客服和工程去忙去吧。
当然，这么干的话很多开发人员会拍砖。
所以、数风流人物还看今朝。看各位了.........
下面是使用模板引擎+JSQLparse实现的过程，开发工具使用Java开发工具，这样的做法你能接受吗。
?
public? procedure? P_users_1001001(UserInfo info){
?/**自定义对象。*/
? DataGrid dg = new DataGrid();
??? /**
?????? sql{
?????????? --userinfo是实体表。
????????????? insert es_system.users (user_code,user_name)
????????????? values
???????????????(:info.userCode,info.user_name);
???????????--查询的值放到data(二维数组)里。
???????????????select * into :data? ?from users where user_code=:info.getUser_code();
???? }
??*/
?? return ProcedureUtil.createProcedure(0,"用户创建成功!!",dg);
}
?
在我的构想中，将开发一个简单的工具，根据上述自动解析出Java原代码，并执行原代码返回执行结果，达到类以于脚本语言的效果。
如果续1的方式不喜欢，这样或许你会喜欢 。
1、SQL语句符合sql92标准。
2、Java标准语法。
3、一个精简的ORM。根据数据库生成对等的JavaBean.数据库的类型与JavaBean的类型对应，校验可以通过标注的方式进行。
?
public? procedure? P_users_1001001(UserInfo info){
?/**自定义对象。*/
? DataGrid dg = new DataGrid();
