数据库的迁移要注意哪些问题

1.程序逻辑部分，新逻辑上线，注意对老逻辑的兼容，千万不要不管三七二十一暴力替换。

2.数据库部分:

1)能建新表尽量建新表以避免对老数据的破坏。

2)如果老表有字段增加，千万不要做非空，唯一性的约束，否则后果自负。

3)假如需要减字段，那么请考虑临时替代的方案，比如新建一张临时表，让程序先取临时表数据，最后等新表建立后再切换过来，导入数据。

3.CACHE等需要序列化，反序列化的部分。一定要兼容原先在缓存中的数据，例如SID千万不要变化，否则反序列化失败，假如有字段需要增加，那么考虑第一次读入先取数据库。

4.外部接口相关的，能不要求外部接口联调，尽量就不做联调，一是麻烦，二是风险大。尽量对原接口传入和传出的数据保持兼容。假如有变化，考虑用适配器封装，实在没办法再实行下策。

5.注意 *** 作的先后顺序，这个也是非常重要，例如你先发了数据库，但是程序还是老的，并且会受到影响，那么就挂了。

数据迁移，是指将正在提供线上服务的数据，从一个地方迁移到另一个地方。按照迁移过程中业务是否中断，可以细分为离线迁移和在线迁移。根据数据所处层次，可以分为cache迁移和存储迁移；根据数据迁移前后的变化，又可以分为平移和转移。

以我三甲医院运行CACHE6年的经历来说，CACHE确实不太适合中国大规模三甲医院使用。数据复杂度高，标准多，更改勤，这是美国医院相对少见的。 医院已经使用CACHE6年多，天天看着这个东西，我相信比那些写q文的人更有发言权。 1. 性能问题：现在不到4000万条记录，1.5T的信息量，CACHE都会速度超慢。查询3个月以上的数据就会死掉。别相信那些CAHCE市场材料宣传的东西。医院系统的复杂性不在绝对记录数量，而在高度的复杂度。 2. 一旦上线，分库困难。数据库越来越膨胀，速度越来越慢，最后小型机用了四年后都不够用了，还得升级小型机。我们医院当年购买ibm小型机可是很快的，可是都赶不上膨胀的速度 3. 死数据。由于OO架构限制，如果对象做了修改，而且又已经有了实例数据，那么这个对象不能进行删除（我是指业务上），时间长了之后，导致垃圾逐渐增多，不少已经定义的实例，导致速度慢，错误多。如果曾经做过OO编程的人，考虑一下定义n多对象并且有两大数据之后，突然要你修改某层对象架构（很多时候还是翻天覆地的变化）的时候，那种感觉和心情。 4. 锁定：Cache的数据库锁机制及其弱智，懒得说。好在医院的数据多是增加，很少有删除的情况，要不早出现很多乱子了。问了几家大型his公司总工级别的人物，对于锁都答非所问。让人心寒。 5. 基于OO的数据库并不成熟。在我多年使用中，感觉不如 RDB + XML的混合方式解决方便。OO非常适合抽象，但是如果这个对象经常都在改，那简直就是生不如死了。有人会说，对象会经常改吗？——那到医院来看看吧。随着医疗信息化的深入，需要改的地方只会增多，不会减少。我们从基于cache信息化厂商那里得到的“不能”已经越来越多了。 6. 资料匮乏：使用的人少，资料奇缺，人材很少。自带的CSP界面极差，功能很弱。编程语言晦涩难看，一点都不优雅（这点是个人意见），上网能找到的文章都是q文，我从来没有在中文网上找到什么非常深入的cache数据库分析文章；公司实力有限（相对于ms，oracle），一个CSP溢出漏洞都要改半天。没有大量的人使用，金子也会变成垃圾。 7. 不知道那些q文里边写的安全性很高是什么意思？我看了半天DOD TCSEC的档案，抱歉，没有发现CACHE的影子 8. 数据迁移问题。现在很多系统，基于RDBMS的，例如oracle、ms sql server 都很容易切换，但是如果转入cache，就像上了贼船，上去容易，下来难了。想后悔都没有机会。不是说绝对不能转换出来，而是很多困难。你没有失败的backup. 9.互联问题。现在健康档案互联，区域医疗信息化等，都是时代发展需要。懂行的人自己考虑一下其中难度，不懂行的人说了也是白说。

---