自从阿里成功实施了去IOE计划以后，目前很多传统企业也希望能跟进。去IOE中最难的应该是如何去O。去O的替代数据库主要有两个著名的开源数据库MySQL和PostgreSQL，以及包括达梦在内的国产数据库。 MySQL和PostgreSQL都是免费、开源的关系数据库，其中MySQL被广泛用于互联网行业，除官方版本外还有不少特色分支，相对PostgreSQL更为流行;PostgreSQL的功能更为丰富，在支持复杂查询方面相对更好一些。至于达梦，是我们自己开发的国产商业数据库，有兴趣的同学可以在这里下载试用：http://www.dameng.com/service/download.shtml
这里列出一些在去O项目实施前需要评估的一些问题，这些问题对选择什么样数据库和实施工作量和风险有一定的参考意义。如果不考虑成本，或者认为老系统已经过时需要彻底重构应用系统，则请忽略下列问题。
1. 老系统是否基于经典的嵌入式Pro*C开发的?
如果回答是，则基本不用考虑使用MySQL, 则应该选择PostgreSQL或者 达梦7，后两者都有嵌入式预编译工具。当然基于MySQL重构整个应用技术上总是可行的。
2. 老系统是否使用了O的特有接口， 如OCI, OCCI?
如果回答是，则选用MySQL或者PostgreSQL都需要换成其他的接口，如JDBC, ODBC等;如果用达梦7，则可以继续使用这些接口;
3. 老系统是否有包括使用了大量的嵌套视图、触发器，相关子查询等复杂SQL特性?
如果回答是，则很遗憾基本不用考虑MySQL, 因为MySQL对复杂查询的支持一直不是很好，当然这个还有改造的余地，改写的工作量相对比较大。
4. 老系统是否基于某个自动生成SQL的中间件，国内很多应用开发商都有这样的中间件，以方便上层应用开发?
如果回答是，则很遗憾基本不用考虑MySQL, 因为这样的中间件通常会生成比较复杂的SQL,而且很难保证连接(JOIN)总是有索引可用。考虑到MySQL的优化器相对欠佳，执行器不支持HASH JOIN, 这些基本不受人工控制的自动SQL将导致极大的性能问题;PostgreSQL的情况也不容乐观，不过对于一些自动SQL复杂度相对不高的场景可以考虑验证评估一下;在这种情况强烈建议一开始就使用达梦7，以节约项目时间。
5. 老系统是否大量使用O的PL/SQL特性?
如果回答是，则不建议使用MySQL或者PostgreSQL。Oracle PL/SQL的很多有趣特性，比如: 引用游标，嵌套表，自治事务等等在MySQL中没有简单明确的对应功能，需要分析具体的业务逻辑并全部重写，这已经不是一个技术问题，需要熟悉应用业务和老系统的处理逻辑。达梦7的PL/SQL兼容性为此类应用的去O提供了极大的便利，因此使用达梦7是一个明智的选择。另外一个选择是基于PostgreSQL的EDB，它也提供大部分PL/SQL兼容特性，EDB应是一个闭源的商业软件;
6. 老系统是否大量使用了O的系统包?
这个问题其实是问题5的进一步扩展。如果选择了MySQL, 并且愿意用MySQL的过程语法改写了PL/SQL的一般逻辑，则O的系统包使用将使得移植更加困难。比如：系统使用了DBMS_LOGMNR包用于挖掘日志信息，或者使用DBMS_LOB包来处理大对象，使用DBMS_SQL包来动态执行SQL，使用DBMS_METADATA来获取数据定义信息，DBMS_RLS包实现VPD等等，达梦7提供了很多重要兼容的系统包，并且还在不断扩展中，可以简化大量的工作。
7. 老系统是否有统计分析报表模块，是否使用了类似分析函数这样的特性?
如果回答是，则选用MySQL将有额外的工作要做，达梦7支持绝大部分O的分析函数特性，PostgfeSQL的支持程度不太清楚，但PG确实支持分析(窗口)函数。报表通常需要扫描较多的数据进行统计汇总，需要高性能的表达式计算，不能说MySQL不能做，但这确实不是它的强项;如果老系统还使用了物化视图，位图连接索引等特性，建议还是尽早考虑达梦7。
8. 老系统是否使用了大量O的SQL 扩展特性?
如果回答是，则不建议使用MySQL和PostgreSQL。这些特性包括：Connect by查询，多列IN, Merge 语句，Cube/Rollup，grouping 等，因为这通常需要改写应用层，把原来的一条SQL修改成若干条SQL, 需要在应用层里实现相同的语义，而不是仅仅换个SQL写法。达梦7提供的兼容特性可以消除这些额外的改写工作。
如果对以上问题的回答都是否定的，那么恭喜你，选择MySQL或许没有太多的移植障碍，但是这样的应用系统通常是不多见的。虽然我不赞成在应用开发中大量使用某一特定数据库的独有特性，但是不同的开发厂商、不同的开发团队都有自己的开发风格，如果没有严格的规范限制，开发工程师通常都有使用这些独有新特性的趋势，部分可能出于彰显其对O的掌握程度的炫耀，而且这些独有特性通常能简化应用程序，何乐而不为呢?
如果选择了MySQL, 团队也愿意辛勤工作准备改写全部需要调整模块，那么理解原来的应用程序变得十分必要，因为改写应用需要遵照原有的业务逻辑，所以需要投入相当的工作量对应用层进行分析以理解一个需要改写的过程，SQL, 或者分析函数的意义，并进行严格的测试，如果出现问题，需要分析是应用层改写出了差异还是数据库层的某个SQL出现了不一致。尽管使用达梦7也需要对移植后的系统进行严格测试，但基本不改应用可以极大简化这部分工作。
推荐访问:加盟需要考虑哪些问题
