目前的情况: 
   1、概况 
  现在公司的项目代码非常的混乱,数据库表的设计也是非常的糟糕,这样,系统的升级和维护变得非常 
  的困难。鉴于此,领导要求将旧系统升级重构。 
  最终英明的领导将这个重任交给了我( ) 
  2、技术概况 
    旧系统是使用jdbc+struts1 
    新系统打算用struts2+hibernate+spring 将会遇到的问题: 
  第一,要改动表吗? 
       这里说的改动表包括,新增表,修改原来的表。 
       最开始我是这样跟领导说的: 
         在这次重构中,不改动表结构,只是代码级别的修改(需充分发挥hibernate的强大能力),以便尽量减少数据迁移的问题。        但是后来我发现,原系统数据库设计很不合理,而且代码也是很乱。如果不改动表的话,难以实现。 
       光是看代码就死人了。 
        目前的话,我打算这样做: 
         旧系统能够用的表尽量用,对于那些设计很差的表,我就打算用新的表来重新设计一下。但是这样, 
         数据迁移会是个很棘手的问题。   第二,数据迁移问题 
        如果不改动旧系统的任何表结构的话,数据迁移问题应该不大。 
        但是,如果我新增了一些表,就得把旧系统的中的数据存到新表中,而旧数据是分很多种类型的,如: 
        基础数据、历史数据、流程数据(最难搞). 
       关于数据迁移问题,我想问的是: 
        如果我新增了一些表,也修改了旧表的结构,请问数据迁移问题可以搞的定吗?一般来说。 
总结提问: 
        目前的话,如果不改动表的话,重构(部分是重新设计)是很难完成的。 
        但是改动表之后,数据迁移也很难搞。请问我该如何做? 

解决方案 »

  1.   

    改数据库是你正确的做法,数据迁移怕什么,集中做,数据割接再数据清理,就看你的sql功底了
      

  2.   

    能用的最好不动,本来工作量就大了,如果都新增的话,工作量就更大了,到时候领导说不定还说你做的太慢。你之前肯定维护了这个系统,业务肯定也不是很陌生,重构问题不是很大,之前没用hibernate,现在迁移过来使用,相信问题不大吧!
      

  3.   

    我们现在的项目也在搞数据迁移,mysql迁移到oracle,档案表一百二三十万条数据,其中空记录和无效记录(前期导数据)达到30万条,经理用pb处理已有数据。介于此,我的意思是是否需要重构,主要还得看项目的大小和已有的数据量,目前我们所做的重构也只是鉴于档案这个核心模块做的,另外,我觉得跟你领导估一个工作量要比是否重构重要的多。
      

  4.   


    系统运行很不正常,也很不稳定,现在公司的开发人员就是维护这个系统。维护的代码实在太大了。
    昨晚跟领导谈了,决定这样做:
      首先不是重构了,而是使用ssh重写原来的代码。但是数据库中原来的表能够用的
      都用,尽量不改动。如果表的设计太差了,就新增表或者新增字段。
      
       我跟领导说了数据迁移的问题,几个领导都说没有问题。
       既然如此,我放手去做了。   谢谢大家热心的回答!