海量数据转换迁移的代码自动生成

系统软硬件升级或者迁移中的数据迁移工作是一项涉及范围很广的工作，往往在源库有数百上千个业务表需要根据一定的模型规则映射到新的数据库中，模型的映射与业务密切相关。通常我们将业务划分为多个域，域内表一级映射可以归纳为以下模型：
1， 一对一映射
2， 一对多映射
3， 多对一映射
4， 多对多映射
由于数据的完整性，安全性考虑，故每一条数据迁移的过程必须要有记录其是否失败的log，以便重传，目前常见的方法是使用etl工具或者自己开发存储过程来实现。ETL工具比如infomatica等，是将映射与代码生成还有数据执行以工具的形式集成了，使得工作人员关注于业务模型的分析，而不是代码的实现和优化，某种程度来说对于迁移过程的标准化，简化有很大的优势。不过缺点也很明显：
1，这类东西都要钱，且是黑盒子；
2，这类东西本身就要花时间去学习使用方法，如复杂的映射和性能优化等
存储过程的缺点也很明显：
1， 开发人员的能力和代码千差万别，后期维护困难，性能方面也不可控
2， 大量的效率低下的编码工作使得项目成本升高
为了解决这些缺点，可以分析常见的映射模型，将代码框架化（一般按照域），并自动生成大量的类型定义，字段排版等人工重复性低效率活动，实现代码结构的统一。这样也容易在后期维护，优化。
代码生成主要根据具体的映射模型，框架代码大概的划分如下：
存储过程通用定义区（通用log或变量申明）
存储过程与业务表相关的定义区（字段或行类型变量申明，游标等）
代码区（批量处理过程，字段赋值，嵌套循环等）
Log区（应用log）
对于前面提到了4种映射模型，其实可以简化为2种，多对多的源表必定是某种逻辑关联的，相当于1对多，同样的多对1简化为1对1，具体在代码中实现就是将多表的关联尽量放在游标循环的外层，这里一般涉及的都是全表转换或者绝大部分数据转换，这种方法也是性能的一个保证。
这种方法生成的代码只是一个框架，业务映射需要程序人员填上，并且一些复杂的逻辑需要手动加上或者对现有代码稍作修改，不在话下。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16179598/viewspace-742348/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16179598/viewspace-742348/