我们需不需要像存储过程一样的跨数据库的JAVA存储过程。

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

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

不错，是哥好点子，感觉只是将O/R 的东西用到存储过程上~，关键是如果有些数据库不支持存储过程咋办，或者支持不好咋办，这个问题就麻烦了~~~

是基于Java的，可以跨数据库。

你说的是存储过程？
1.有数据时你怎么才可以有个“干静的环境”？调试？
2.随时可以查看其原代码？你是说把所有代码写在一个文件中？
3.你是说你在不知道所有表，是否触发器情况下能明白数据的来源？

对于不到20个逻辑的一个请求存储过程有着天生的优势 ，就如同PHP一样，快但脏

1、存储过程可以随时的查看原代码，对于存储过程的修改十分的方便，数据库都会提供调试工具。入口明确。
我们要做的就是用Java去模访它。
2、同样我们要做到随时可以查看代码，更改代码并运行。
3、你在开发存储过程时，只关心写sql以及关心获取什么样的值，存储过程有问题时，可以直接查看，相对于Java而言来得方便 。

就是业务逻辑+跨数据库吧，规则引擎可以把业务逻辑这样管理起来，不知道是不是可以直接连持久化一起做成规则，就符合你的需求了吧？
我也不大清楚规则引擎。。。

这样做和传统企业开发的tuxedo之类的中间件有什么明显优势吗？把计算从数据库中抽出来形成中间层，这正是3层应用的最初想法呀。

你可以回头看看现在的中间层都做了什么？其实我个人的想法也是在中间层的运用能够更上一层楼，而不是SSH之类的东西，我希望中间层能够更精简，不是现在一堆的DAO之类的东西。

逻辑中间件更注重流程，而且它很复杂,我更希望它更精简。

存储过程易于调试？ 要打问号吧

存储过程也不一定性能良好，处理集合时快，业务逻辑时慢