从一个DBMS迁移到另一个DBMS[关闭]

在我看来,不利用您使用的数据库的所有功能是愚蠢的。无论使用多少功能,都很难更改DBMS。系统之间存在微小的差异(如一些记录日期和一些记录日期和时间),这将导致非常头痛的更改。根本不存在切换到新dbms的情况。

我们这样做是因为我们在旧dbms上运行的系统太大了。数据太多了,我们需要更强大的东西。此外,它不再受支持。

有了这种混乱,我建议您可以迁移大型项目,只要您能够成功地将数据层与任何逻辑代码完全分离。如果你能做到这一点,那么你就可以在数据层实现任何数据库功能来加速应用程序,而不会影响你的核心应用程序。

切换了很多次。主要是因为“非自愿转换”——旧产品不再受支持或不再适用。

• DB2到Oracle。UDB之前的数据被保留并移动到Oracle中。
• MS访问Oracle。继续通过Oracle表使用Access前端。

“你为什么要这么做?”不是特写。不是成本。在所有情况下,都有东西坏了。

• 旧产品没有规模。

切换很少是你选择做的事情。当供应商停业(安格尔做过一次)或停止支持您的版本(微软经常做这件事)时,您会被迫这样做。

更重要的是,数据库中的“东西”(存储过程、触发器等)越多,您的应用程序软件就越成为一堆难以理解(也难以维护)的乱七八糟的东西。没有什么比等待几个星期来有人跟踪存储过程名称更令人沮丧的了。如果是VB代码,每个人都可以访问它。但由于它在数据库中,矛盾的是,它变得不那么明显了。代码就是代码,应该远离数据。

Where to put your code - Database vs. Application? 有关此主题的更多信息。

我参与了几个将数据从一个数据库迁移到另一个数据库的项目。在任何情况下,都是数据被迁移,而不是RDMBS。如果应用程序正在工作,那么就不会有为了切换而切换数据库的压力。迁移的动力通常是因为旧系统的数据要么过时,要么不兼容,要么两者都不兼容,这也提供了切换RDBMS的机会。

结果是,这些项目几乎总是对数据、模式和代码产生巨大影响,而将T-SQL转换为PL-SQL所需的任何工作都只是项目的一小部分。因此,如果您要为一个好的RDBMS付费,请全部使用。否则的话,就好比不使用你新车的行李箱或杂物箱,这样在你买新车时就更容易换车了。

另一点(支持S.Lott)。根据您的开发环境,您的开发人员可能无法轻松地开发甚至查看存储过程。在两套不同的开发工具和执行环境之间拆分应用程序代码可能会变得复杂,并且会使寻找熟练员工变得更加困难。

我不认为这是一个反对存储过程的论据,但在决定代码应该驻留在您的应用程序的给定组件时,这当然是一个需要考虑的问题。

我们做了HP3000到Oracle的迁移。这花费了我们2500万美元,同时也增加了数据损失2亿美元的成本,因为他们太匆忙了,根本不考虑自己在做什么。我也发现了很多地方,只是把它看作是一种移动。他们会在晚些时候解决剩下的问题……很久以后。