? ? 我主要负责了数据库的设计，以及报表模块的实现等。现就技术问题总结如下。

首先，数据库的设计是非常重要。在以前的项目中，我所在小组就曾因忽视了数据库设计以及测试数据的添加，而令项目迟迟无法如期展开。

但是刚开始，我们为了避免麻烦，把很多多对多的关系改成了一对多关系，后期才发现这样会产生很多问题，如表之间不能按需求所要求的逻辑查询等。因此，发现还是应严谨些，不能图一时之利，否则后患无穷。

数据库数据的添加，虽然可以用PL/SQL Developer导入Excel数据，但仍然是件麻烦的事情。各表之间各有联系，编码人员时时都在进行增删查改的测试。因此，以后可以考虑，数据库的备份与恢复，或各个编码人员各创建一个数据库用户来对数据库进行操作，避免互相影响，这些肯定比每次都导入数据来得高效。

其次，报表模块，不同于用户模块、订单模块、车辆模块等常规模块。个人觉得，报表中的内容来自于其他模块，如果报表是一个表，就会造成数据冗余，表过多等问题，可能造成数据不一致的问题，如果要保持一致，就要设计大量的触发器。因此，报表应该是建立在其他模块之上的视图，更方便，也更安全。

同时，视图的名称要与报表时间相关，是动态确定的。因此，考虑用Oracle的定时任务Job来为我们按月、按季度、按年调用相应的存储过程来生成报表。这些存储过程首先会组合出正确的报表名称，然后生成报表视图，最后将这个报表内容的一般信息，如报表时间、生成时间、相关单位，以及统计信息，如总重量、总体积、总价格，加入一个报表总汇表中存储起来。

报表总汇为何是表，而不是视图？如果是视图，就无法按需求存储报表时间、生成时间、相关单位等额外信息；如果是表，就会因为某些订单内容的修改，导致报表内容的变化，产生与报表总汇的统计信息的不一致的问题，解决方法有两种，一是通过触发器，但触发器针对的是表，不能是视图，这就仍然要设计大量的触发器，二是交由项目的权限控制来解决，如不能对上个月的订单表等表进行增删改，而应该在这个月做出相应的撤销或增添部分订单的动作，在咨询过专业人员后，发现这样比较符合实际情况，但是由于财务方面知识有限，这方面的尝试就暂时搁置了，假设了报表的生成肯定在增删改操作之后。

由于测试的需要，暂时没有用Job来生成报表，而在web上开放了这个接口，让用户可以手工生成。由于使用了存储过程，封装了大量的操作，因此在报表模块的代码编写时，就十分简单。需要注意的是，虽然视图可以利用Hibernate工具来反向生成，但是我们的视图名称并不是固定的，数量也大，不应该生成大量的视图实体来控制，也不可能有DAO来对视图内容增删改，因此如果要得到报表视图的内容，只需自己封装一个POJO，而后就可以正常查看与表现了。

以上就是报表模块的背后思想，关于报表的表现方式，我选择了轻量、跨平台的HighChar