有没有人有从一个DBMS迁移到另一个DBMS的经验？如果你这样做了，你为什么这样做？特征？成本？公司指令？
有时，我与DBA一起工作，他们坚持认为我们不使用特定于DBMS的功能（例如，SQL Server中的CLR存储过程。）DBA的观点是，如果我们使用这些功能，它将会成功如果必须，更难以切换到另一个DBMS。但到目前为止，我从未被要求转换。
答案 0 :(得分：4)
在我看来，愚蠢的是不要利用你使用的数据库的所有功能。无论您使用多少功能，更改DBMS都会很困难。系统之间存在微小差异（如某些记录日期和某些记录日期和时间），这将导致巨大的改变。没有这样的东西只是切换到新的dbms。
从业务角度来看，还有很多工作要做。分析新的dbs改为。弄清楚改变dbs对新系统的影响。开发改变现有系统，测试更改等。列表一直在继续。在企业系统上进行这样的切换需要数月甚至数年。我工作的最后一个地方不得不改变dbs，我们花了11个月的时间来完成这项工作，并且花了大约200万美元用于顾问，硬件，软件和员工工资。这是一个大问题。如果有人说不使用功能，因为有一天“可能”发生并且更容易做，很可能，那个人不在他们的摇杆。与其他一切（最有可能）相比，转换这些功能所需的额外时间和金钱是微不足道的。 IMO如果能节省时间和金钱现在购买使用这些功能，那么这是最好的行动方案。
我们这样做是因为我们在旧dbms上运行的系统太大了。数据太多了，我们需要更强大的东西。此外，它不再受支持了。
答案 1 :(得分：3)
多次切换。主要是因为“非自愿转换” - 旧产品不再受支持或不再适用。
“你为什么这么做？”不是功能。不花钱。在所有情况下，某些事情都被打破了
切换很少是您选择做的事情。当供应商停业时（Ingres这样做了一次）或者停止支持你的版本（微软经常这样做），它会强迫你。
然后，当然，这是一场危机。由触发器和存储过程更改的技术复杂性组合而成。如果只是数据，那就不会是危机了。转储到某个标准格式（例如CSV），重新加载，然后启动并运行。
更重要的是，数据库中的“东西”（存储过程，触发器等）越多，您的应用程序软件就越成为一堆令人困惑的难以理解的（并且难以维护的）kludges。没有什么比等待几周跟踪存储过程名称的人更令人沮丧的了。如果是VB代码，那么每个人都可以访问它。但由于它存在于数据库中，因此它变得不那么明显了。代码是代码，应远离数据。
有关此主题的更多信息，请参阅Where to put your code - Database vs. Application?。
答案 2 :(得分：3)
我在一家公司工作了很多年，其产品支持Oracle或SQL Server。我们在Erwin中维护了模型，并从中生成了模式脚本，触发器和Oracle包。这些包用于使Oracle触发器与SQL Server一起工作（具有逻辑'插入'和'删除'表）我们保留了两组存储过程脚本。
有了这个烂摊子，我建议您可以迁移大型项目，只要您可以成功地使您的数据层完全独立于任何逻辑代码。如果你能做到这一点，那么你可以实现任何数据库功能，从而加速数据层中的应用程序，而不会影响您的核心应用程序。
答案 3 :(得分：2)
我参与了几个项目，将数据从一个数据库迁移到另一个数据库。在每种情况下，都是正在迁移的数据 - 而不是RDMBS。如果应用程序正在运行，那么为了切换而切换数据库不会有任何压力。迁移的动力通常是因为旧系统的数据过时，不兼容或两者兼而有之，这也为切换RDBMS提供了机会。
最可能的变化是将参考数据（员工，客户等）合并到现有主数据库中（为了一致性和易用性），然后修改所有其他表，以便密钥指向新的参考数据。这需要架构和相应的代码在堆栈中上下变化。这是数据迁移 - 而不是数据库迁移。您很可能希望利用这个机会来添加数据，或标准化名称，或者（de）-normalize the tables等。
结果是这些项目几乎总是对数据，架构和代码产生巨大影响，并且将T-SQL转换为PL-SQL所需的任何工作都将是一个非常小的部分该项目。因此，如果您要为一个好的RDBMS付费，请使用它。否则就像不使用新车的行李箱或手套箱，以便在购买新车时更容易换车。
答案 4 :(得分：1)
另一点（支持S.Lott）。根据您的开发环境，开发人员可能无法轻松开发甚至查看存储过程。在两组不同的开发工具和执行环境之间拆分应用程序代码会变得复杂，并且可能使找到熟练的员工变得更加困难。
我认为这不是针对存储过程的论据，但在决定应用程序的给定组件应该驻留代码的位置时，肯定需要考虑这一点。
答案 5 :(得分：0)
我们做了HP3000到Oracle的迁移。它花了我们2500万美元，并且还增加了损失2亿美元数据的成本，因为他们没有想到他们在做什么。此外，我发现很多地方只是将其视为一个举动。他们稍后会弄清楚其余的.......很久以后。