[color=red]目前的情况：[/color]
[b]1、概况[/b]
现在公司的项目代码非常的混乱，数据库表的设计也是非常的糟糕，这样，系统的升级和维护变得非常
的困难。鉴于此，领导要求将旧系统升级重构。
最终英明的领导将这个重任交给了我( :cry: )
[b]2、技术概况[/b]
旧系统是使用jdbc+struts1
新系统打算用struts2+hibernate+spring
将会遇到的问题：
第一，要改动表吗？
这里说的改动表包括，新增表，修改原来的表。
最开始我是这样跟领导说的：
在这次重构中，不改动表结构，只是代码级别的修改(需充分发挥hibernate的强大能力)，以便尽量减少数据迁移的问题。
但是后来我发现，原系统数据库设计很不合理，而且代码也是很乱。如果不改动表的话，难以实现。
光是看代码就死人了。
目前的话，我打算这样做：
旧系统能够用的表尽量用，对于那些设计很差的表，我就打算用新的表来重新设计一下。但是这样，
数据迁移会是个很棘手的问题。
第二，数据迁移问题
如果不改动旧系统的任何表结构的话，数据迁移问题应该不大。
但是，如果我新增了一些表，就得把旧系统的中的数据存到新表中，而旧数据是分很多种类型的，如：
基础数据、历史数据、流程数据(最难搞).
关于数据迁移问题，我想问的是：
如果我新增了一些表，也修改了旧表的结构，请问数据迁移问题可以搞的定吗？一般来说。
总结提问：
目前的话，如果不改动表的话，重构(部分是重新设计)是很难完成的。
但是改动表之后，数据迁移也很难搞。请问我该如何做？
这肯定可以搞定的啊，只是工作量多少的问题
如果这个项目以后不归你维护，何必自讨苦吃呢？
较为负责任的办法，我觉得是把合力的数据库结构整理出来，把工作量估计出来（千万不要高估自己的效率），然后让领导决定是否变动库表结构
目前有多少类？你做过hibernate/spring/struts2么？你做过类似的迁移么？没有做的话，做好准备，这个项目难度不亚于重建一个系统，而且结果也未必理想。比较保守的建议是在现有代码的基础上，重构数据库。不要为了ssh而ssh，一个能够正确运行的程序就是好程序了。