基于Oracle的报表功能的一种解决方案——中软实习项目总结

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

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

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

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

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

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

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

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

以上就是报表模块的背后思想,关于报表的表现方式,我选择了轻量、跨平台的HighCharts。数据的绑定,只需将struts的相关标签写入相应js文件即可。

空余时间,又给订单增添了二维码扫描,这个其实十分简单,站在Google的肩上,直接用它的API,传递一些参数给URL就完成。我们的项目都部署在本地,如果手机可以与本地一个网段,就直接传递该订单的网址,更方便查看。二维码方面可以有更多的扩展。

扫描二维码关注公众号,回复: 1282522 查看本文章

其次,想利用百度地图API来为订单配送路径设计地图弧线,使其能以一种更动态更新颖的方式来呈现,但是中软的网络无法登录百度API平台,且其key的权限问题我还没有搞透,时间有限,只能留待以后探索。

猜你喜欢

转载自zjh776.iteye.com/blog/1912850
今日推荐