技术选型带来的困扰

如果持久化层使用Spring（JdbcTemplate），那么分页功能的实现依赖于数据库吗？也就是说目前采用的是DB2，以后要移植到ORACLE，分页功能需要改吗？

以我的经验谈谈我的个人看法:
1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。
2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。
3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。
4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。
5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。
6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。
7、方案，存储过程+Hibernate

个人看法。

从DB2向Oracle迁移？如果这样的话，建议数据持久化用Hibernate，统计等大数据操作可以使用PL/SQL,速度要快很多。当然，如果你非要考虑数据库的可移植性等等问题，那么PL/SQL可能并不适合你

以我的经验谈谈我的个人看法:
1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。
2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。
3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。
4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。
5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。
6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。
7、方案，存储过程+Hibernate

个人看法。

以我的经验谈谈我的个人看法:
1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。
2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。
3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。
4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。
5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。
6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。
7、方案，存储过程+Hibernate

个人看法。

1.原有系统大约有200多张表，冗余表很多。在抽象数据模型时，我在考虑一部分采用原有的数据模型，另一部分将根据业务需要自己创建数据模型。
2.使用struts+hiberntate查询时，将返回值装配到List中抛出Java.lang.OutOfMemoryError: Java heap space。（测试数据库postgreSQL8）
查询代码如下：
public List<Employee> selectAllEmployee() {
// TODO Auto-generated method stub
Session session = null;
List<Employee> list = new ArrayList<Employee>();
try {
session = HibernateUtil.currentSession();
Query query = session.createQuery("from Employee ");
list = (List<Employee>) query.list();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
System.out.println("<<-------------" + e.toString());
}

return list;
}

以我的经验谈谈我的个人看法:
1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。
2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。
3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。
4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。
5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。
6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。
7、方案，存储过程+Hibernate

个人看法。