升级Informix-切换到Oracle、Sybase还是继续使用Informix？

之前我在这里发布了一个问题，以便确认我们当前（尽管是过时的）Informix版本：

（感谢乔纳森和雷特澄清此事）

我们肯定在计划升级，但首先要讨论的是，现在迁移到Oracle或Sybase是否更有意义。你对此有何看法？我相信，虽然所有3个RDBMs都有自己的独特性，但它们必须基本上覆盖相同的领域。那么，如何决定使用哪个数据库呢

最重要的是，我需要知道如果我们升级Informix（目前使用7.13），我们是否需要修改嵌入式SQLC程序？如果没有，那么坚持使用Informix是很有意义的。因为如果我们使用Sybase/Oracle等，我们将需要大量的工作来更新后端程序

但是如果切换到另一个数据库可以提供比较大的回报，那么我们仍然会考虑它。我期待着听取您的意见。

我是一个有偏见的观察者（我在IBM的Informix上工作）-请谨慎对待我的意见

如果您的应用程序是用Informix ESQL/C编写的，那么您将不得不进行大手术才能将它们转移到其他系统。您需要决定使用哪个替代接口—您的跨平台选择（以C为基本语言）是ODBC，但Oracle提供OCI，Sybase提供TDS作为替代

相比之下，使用Informix ESQL/C，升级到当前版本（Informix ClientSDK 3.50，包含ESQL/C 3.50，它比您当前使用的ESQL/C 6.00更新）应该是无痛的，除非您特意编写了糟糕的代码

即使只是简单地迁移数据，也可能会带来一些创伤——并非无法克服。在某种程度上，复杂性取决于您使用的数据类型。（例如，字符串很容易迁移；日期和时间值不那么容易。）但是迁移应用程序将需要大量的工作，正如您所说的，除非您非常有先见之明并编写了一个非常好的数据抽象层

升级到Informix SE 7.26将是一件轻而易举的事——获取软件，安装它，将它指向您现有的数据库。您可能希望重新编译您的程序以使用更现代的CSDK，但是您可以谨慎地以增量方式进行（两个INFORMIXDIR值，一个用于旧代码，一个用于新代码）

升级到Informix Dynamic Server（IDS）11.50需要您从SE导出数据（DB导出）并将其导入IDS。这将是非常简单的，一旦你有了ID和运行。启动和运行IDS比SE需要更多的努力，但并不那么难

显然，我的建议是继续使用Informix。当然，这是你的决定

---

有了ID，我们需要修改代码还是重新编译

IDS与SE关系非常密切，但它们是不同的。IDS提供了几乎严格的SE功能超集。我能想到的不同之处主要是边缘案例：

• SE有额外的语法来创建用于为数据库定位C-ISAM文件的表；IDS有一组完全不同的扩展。基本的CREATE表是相同的（虽然IDS有SE没有的类型，比如VARCHAR），但是装饰是不同的
• SE有创建审核和删除审核，而IDS没有（它有其他审核功能）
• SE有启动数据库和前滚数据库；IDS没有（恢复和登录IDS是不同的）

可能导致问题的主要方面是事务管理。IDS和SE一样，都有未标记、已记录和“日志模式ANSI”数据库。在IDS中，我们鼓励您使用日志数据库——这将是一个强烈的建议。IDS在记录的数据库中提供原子语句——要么语句作为一个整体工作，要么作为一个整体失败。然而，许多SE应用程序在编写时并没有考虑事务。当数据库上有事务时，有些事情是不能做的，例如在事务范围之外打开游标进行更新。这就是代码从SE迁移到IDS的原因。此外，除了在事务中，您无法锁定表，并且除了通过提交或回滚，您无法解锁表

问题的严重程度取决于您在SE中使用了什么以及程序是如何设计的（如果它们是设计的而不是组合在一起的）。IDS未标记的数据库和SE未标记的数据库非常接近，您可以从一个数据库迁移到另一个数据库。但是IDS只能在数据库被记录的情况下做一些事情（比如复制），并且您应该瞄准使用记录的数据库

---

然而，迁移到CSDK 3.50应该只是一个重新编译，除非你做了一些非常可怕的事情。

关于Informix消亡的谣言被大大夸大了

随着您对嵌入式代码的投资，任何明显的标签价格成本节约都会很快在重新开发成本中消失。这只是生活中的一个事实：我见过一些项目为了每年节省2万美元的许可证而在重建中耗资超过10万美元。那钱花得不好

你会想非常非常肯定的是，RDBMS的转换将提供一些你在坚持现有的基础上确实无法实现的东西。因为风险（来自痛苦的经历——我与之斗争了很长时间）是你可能会花很多钱和时间在原地奔跑，如果不是倒退的话

如果您要退一步，从整体上看待您的问题，我认为您最好评估更新的、松散耦合的、与数据库无关的体系结构的可能性，而不是将一个嵌入式模型替换为另一个。这将为您提供更大的灵活性

希望能有帮助。

我们有