历史数据迁移总结

 这段时间一直忙于一个项目的历史数据迁移，这期间遇到的问题千奇百怪，可以说杯具是接二连三。现将这些问题简单总结一下：

第一个问题：不知道老系统的数据库结构和代码的结构，客户只给了我们一个运行包和dmp文件，一下子不知道如何还原老系统的环境，在纠结中不停的百度，

后来通过Reflector.exe工具将原来的文件进行反编译，渐渐的对里面的代码进行分析，搭建环境。

第二个问题：不知道数据库中字段的含义，现在想想都觉得恶心，数据库字段命名竟然采用XX1，XX2,xx3的方式，并且没有一句注释，当时就特痛恨之前的那些开发人员，怎么就不为后来的人着想呢（软件开发中的备注真是不可缺少啊），为了将数据库字段与页面中的字段的进行对应，这项工作折磨了我好几天，只能通过页面上的值和数据库中的值进行比对，从而去判断数据库字段的含义，并且把这些字段添加备注。（当我把这项工作搞完时发现已经可以重新把原来的数据库重新设计一下了）

第三个问题：新老系统的如何进行对应？虽然用户也很热情的给我介绍相关的业务逻辑，可是悲催的是新系统的数据库也不是我设计的，（后来才参与这个项目的），新老系统的数据库设计风格完全不一致，而且新系统还增加了很多的新功能，同时也删减了部分老功能，同一个业务表，新老系统中存的数据也存在着很多的差异。为了向新系统中导入老系统的数据，我整天就泡在oracle的脚本中（后来自己都发现很佩服自己，发现写脚本的的能力得到了大大的提升，那么恶心的东西都被整理的井井有条，如此说来只要用心，多花工夫，还没有解决不了的问题），每一个改动都用脚本进行记录（这个经验以后也一定要保持，在正式导入时这些脚本可相当的给力，否则那么多问题，若是没有这些记录，时间久了哪里知道这些数据为什么要这样处理）。

第四个问题：数据虽然导入成功，但是业务逻辑就是否正确呢？为了解决这个问题，测试的功劳不小，测试能暴露很多的问题，同时也发现了脚本的不完善性，从而就不断的测试--完善脚本--再测试--再完善脚本……一直到所有的问题都解决，这个过程的痛苦不亚于前几着，虽然这项工作有痛苦，但是最终当完成整个数据的迁移时，那种喜悦还是觉得值得的。

总之：无论问题多么的怪，无论问题多么的大，罗列一下，耐心细心的按个去解决，最终这些问题都会被解决的，当这些问题都被解决的时候自己也进步了，同时能力也得到了相应的提升！