技术选型带来的困扰

公司接到一个ERP系统改造的项目，数据库采用原有的AS400上的DB2 5.4。数据量巨大，大约有30年的历史了，而且表之间没有关联关系。由于本人技术能力有限，所以在技术选型时感到很迷茫。迷茫的原因是一方面要考虑到系统性能问题，另一方面还要考虑开发的难易程度和系统健壮性，等等一系列问题。
我将目前比较流行的技术方案分别做了一个demo，并且以查询10万条数据为标准做性能测试。结果如下：

方案名称                第一次执行耗时 第二次执行耗时 第三次执行耗时
Struts+Jdbc                 2192ms 1315ms 1299ms
Struts+Spring(JdbcTemplate) 2335ms 1317ms 1299ms
Struts+Ibatis                 3081ms 1525ms 1458ms
Struts+Spring+ibatis         4172ms 2969ms 2938ms
Struts+Hibernate    Java.lang.OutOfMemoryError: Java heap space

测试方法是在Action中调用DAO中的方法，在调用方法前和返回数据后，打印当前时间来计算查询所耗费的时间。
开始的时候想采用Struts+Spring+ibatis这个方案，但是通过测试后，发现这个方案的耗时要比采用Struts+Spring(JdbcTemplate)高出将近2秒。Struts+Spring(JdbcTemplate)在性能上占有一定的优势，可是在编写代码上总是给人一种不太舒服的感觉，代码如下：
public List<Employee> getEmployeeList() {
  
// TODO Auto-generated method stub
String sql = "select * from employee where id<?;";

return jdbcTemplate.query(sql, new Object[]{100000}, new RowMapper(){
public Object mapRow(ResultSet rs,int index)throws SQLException{
Employee employee = new Employee();
employee.setId(rs.getInt("id"));
employee.setDempId(rs.getInt("emp_id"));
employee.setEmpId(rs.getInt("dept_id"));
employee.setFirstName(rs.getString("first_name"));
employee.setLastName(rs.getString("last_name"));
employee.setJobCat(rs.getString("job_cat"));
employee.setSalary(rs.getInt("salary"));

return employee;

}


});


}
可能一直使用Hibernate的原因吧，总感觉这段代码不太舒服。而且Spring(JdbcTemplate)没有提供分页功能，实现起来比较麻烦。
希望各位高手能给在下一些建议？谢谢先！



2008/05/07补充：
由于昨天没机会看帖子，今天刚回来就看到这篇帖子已经出现在了首页。
激动之余发表两点感谢：
1.狂谢热心参与本次讨论的各位朋友们，小弟将会把最终的项目案例与大家分享，希望能为中国软件事业的崛起贡献微薄之力。
2.感谢javaeye提供了这样好的交流平台，希望今后越做越好。

实际上SSH这个架构，已经算是相当成熟了，对于hibernate，可以使用一些性能优化的方式，robbin好像有相关的一个帖子，性能上还是比较不错的，我们现在的项目，持久层是基于hibernate与iBatis的，hibernate主要是用来保存对象，而一些复杂的查询，则使用iBatis来生成SQL，最终交由hibernate处理(可以看一下appfuse的方式)，个人感觉性能还是不错的，至于表现层，可以选择的还是比较多的，这个，要看贵公司的开发人员的表示层框架的熟悉程序以及深度了。

AX400？ AS400？
用10万条来做性能测试，靠谱么？是不是数据量太小了点。至少要百万往上吧。
不太明白为什么struts+hibernate会outof memory, 10万条都取出来也没多少内容。>100M?
这么点数据查询就这么慢，数据库有问题吧，或者代码逻辑有问题。

我觉得有几方面比较关键，
新的数据模型如何能够兼容旧模型又能满足业务要求。
数据如何移植，从旧数据模型映射到新数据模型中。
关键数据 数据量有多大。

涉及遗留数据库用ibatis为好

你这个用例太难得了，希望能多交流。

能不能详细说明下，什么样的情况下 涉及遗留系统用ibatis好，好处在什么地方？

遗留系统一般以数据库为核心，很多系统的数据库表设计并不符合OO设计的原则，如出于性能考虑而出现的大聚合表：用单表的若干组字段代替若干个主从表结构。

举个大聚合表的实例：一个税务系统的纳税人缴款单表，10年前基于PB设计的sybase库，一个表有230多个字段，包含纳税人信息、30多个税种交欠数据、滞纳金信息、税种退税规则设定......，用Hibernate来处理会很别扭，用ibatis就方便得多。

虽说真正符合关系数据库设计原则的表设计并不和OO映射矛盾，但对于遗留系统，在当时有很多的理由采取各种非正规的表设计方式：大聚合表、离散表、多重冗余，对于这些表，sql层面的灵活性就十分重要！

接楼上的说明，解释的很清晰，我的问题就在于：
lz并没有说明改造要采用原来的数据模型，需要lz明确。
如果采用新的数据模型，就可以考虑不用ibatis，具体情况具体分析。
我通过对lz描述的意图的猜测是，要采用新的数据模型，把就有系统中数据移植，转换到新的模型下。

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;
}

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

你先考虑数据库迁移，再考虑什么技术框架，数据库迁移就是一个浩大的工程。你的技术框架是建立在DB之上的。