旧系统重构，数据迁移问题

[Sam_Deep_Thinking]

目前的情况：
1、概况
现在公司的项目代码非常的混乱，数据库表的设计也是非常的糟糕，这样，系统的升级和维护变得非常
的困难。鉴于此，领导要求将旧系统升级重构。
最终英明的领导将这个重任交给了我( )
2、技术概况
旧系统是使用jdbc+struts1
新系统打算用struts2+hibernate+spring

将会遇到的问题：
第一，要改动表吗？
这里说的改动表包括，新增表，修改原来的表。
最开始我是这样跟领导说的：
在这次重构中，不改动表结构，只是代码级别的修改(需充分发挥hibernate的强大能力)，以便尽量减少数据迁移的问题。

但是后来我发现，原系统数据库设计很不合理，而且代码也是很乱。如果不改动表的话，难以实现。
光是看代码就死人了。
目前的话，我打算这样做：
旧系统能够用的表尽量用，对于那些设计很差的表，我就打算用新的表来重新设计一下。但是这样，
数据迁移会是个很棘手的问题。

第二，数据迁移问题
如果不改动旧系统的任何表结构的话，数据迁移问题应该不大。
但是，如果我新增了一些表，就得把旧系统的中的数据存到新表中，而旧数据是分很多种类型的，如：
基础数据、历史数据、流程数据(最难搞).
关于数据迁移问题，我想问的是：
如果我新增了一些表，也修改了旧表的结构，请问数据迁移问题可以搞的定吗？一般来说。


总结提问：
目前的话，如果不改动表的话，重构(部分是重新设计)是很难完成的。
但是改动表之后，数据迁移也很难搞。请问我该如何做？

[donghua123]

原系统是什么系统？可否发来看看？

[Sam_Deep_Thinking]

没有人遇到重构的情况吗？
没有人回答？

[itparadise]

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

[同光和尘]

关注————

[pigofdengchunyan]

目前我也遇到这样的问题，由于数据库结构的限制，要想新增一些功能，感觉真的是很棘手，不知道从何下手，修改数据库表结构，数据库的迁移问题又是一个难题，不修改，视乎新增功能很难实现，个人觉得要维护一系统，需要本身那个系统的交互性一定要强，设计要合理，不能后期维护真的是一个很大的问题

[dahaidao]

都重新开始吧，以新的系统的设计为主，再考虑旧的。

如果对业务不熟的话，想看懂原来的，一定有困难，想设计新的，更有困难。

实在不行，旧的就不要再用了。

[火龙果被占用了]

这哪是重构啊？这等于重写！

[IOshopping]

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

[IOshopping]

重构 改版 升级 都是在原来基础上做的 不是重做

[yang4187668]

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

[dr_lou]

1、此系统运行是否正常？稳定？
2、是否有频繁的新需求添加？
3、维护成本与重写成本比是多少？

[Sam_Deep_Thinking]

火龙果先生,有什么好建议呀？

[火龙果被占用了]

说服你们领导“能用就不要去动”，这是重构和优化最重要的原则！

[Sam_Deep_Thinking]

[Quote=引用 13 楼 dr_lou 的回复:]
1、此系统运行是否正常？稳定？
2、是否有频繁的新需求添加？
3、维护成本与重写成本比是多少？
[/Quote]

系统运行很不正常，也很不稳定，现在公司的开发人员就是维护这个系统。维护的代码实在太大了。
昨晚跟领导谈了，决定这样做：
首先不是重构了，而是使用ssh重写原来的代码。但是数据库中原来的表能够用的
都用，尽量不改动。如果表的设计太差了，就新增表或者新增字段。

我跟领导说了数据迁移的问题，几个领导都说没有问题。
既然如此，我放手去做了。

谢谢大家热心的回答！