升级 Informix - 切换到 Oracle、Sybase 还是继续使用 Informix？
之前我发布了一个问题，以便我可以在此处确认我们当前（尽管过时）的 Informix 版本：
（感谢 Jonathan 和 RET 的澄清）
我们确实计划升级，但首先讨论迁移到 Oracle 或 Sybase 是否更有意义此时。 您对此有何看法？ 我相信，虽然所有 3 种 RDBM 都有其独特性，但它们本质上必须涵盖相同的基础。 那么如何决定使用哪个数据库呢？
最重要的是我需要知道如果我们升级 Informix（当前使用 7.13），我们是否需要修改我们的嵌入式 sql C 程序？ 如果没有，那么坚持使用 Informix 就很有意义。 因为如果我们使用 Sybase/Oracle 等，我们需要做很多工作来更新后端程序。
但如果相比之下切换到另一个数据库可以提供巨大的回报，那么我们仍然会考虑它。 我期待听到您的意见。
Previously I posted a question so I could confirm our current (albeit archaic) version of Informix here:
How do you identify Informix version on Solaris?
(Thank you Jonathan and RET for clearing that up)
We are definitely planning on upgrading but are first discussing if it would make more sense to move to Oracle or Sybase at this time. What are your opinions on this? It's my belief that while all 3 RDBMs have their own uniqueness, they must all cover the same ground essentially. So how does one go about deciding what database to use?
The big kicker is I need to know if we upgrade Informix (currently using 7.13), will we need to modify our embedded sql C programs? If not, then it makes a lot of sense to stick with Informix. Because if we went with Sybase/Oracle etc, we'd have a lot of work on our hands to update the back-end programs.
But if switching to another database can offer great return in comparison then we will still consider it. I look forward to hearing your opinions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我是一个有偏见的观察者（我在 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-Export) 并将其导入 (DB-Import) 到 IDS。 一旦 IDS 启动并运行，这也将非常简单。 启动并运行 IDS 比 SE 需要更多的努力，但也不是那么难。
显然，我的建议是继续使用 Informix。 当然，决定权在你。
IDS与SE密切相关，但又有所不同。 IDS 提供了几乎严格的 SE 功能超集。 我能想到的差异主要是边缘情况：
可能导致问题的主要领域是事务管理。 IDS 具有未记录、记录和“LOG MODE ANSI”数据库，SE 也是如此。 在 IDS 中，鼓励您使用记录数据库 - 这将是一个强烈的建议。 IDS 在记录的数据库中提供原子语句 - 该语句要么作为一个整体工作，要么作为一个整体失败。 然而，许多 SE 应用程序在编写时并未考虑到事务。 当数据库上有事务时，有些事情是不能做的，例如在事务范围之外打开游标进行更新。 这就是从 SE 迁移到 IDS 时容易出现问题的原因。 此外，除了在事务中之外，您无法锁定表，并且除了通过 COMMIT 或 ROLLBACK 之外，您也无法解锁表。
这会造成多大的问题取决于您在 SE 中使用的内容以及程序的设计方式（如果它们是设计的而不是拼凑在一起的）。 IDS 无日志数据库和 SE 无日志数据库非常接近 - 您可以从一个迁移到另一个。 但只有当数据库被记录时，IDS 才能执行某些操作（例如复制），并且您应该致力于使用记录的数据库。
然而，迁移到 CSDK 3.50 应该只是重新编译，除非您已经成功地做了一些非常可怕的事情。
I'm a biassed observer (I work for IBM on Informix) - treat my comments with due caution.
If your applications are written in Informix ESQL/C, you would have to do major surgery to move them to other systems. You would need to decide which alternative interface to use - your cross-platform choice (with C as the basic language) is ODBC, but Oracle provides the OCI and Sybase provides the TDS as alternatives.
By contrast, with Informix ESQL/C, an upgrade to the current version (Informix ClientSDK 3.50, containing ESQL/C 3.50, which is more recent than the ESQL/C 6.00 which you currently use) should be painless unless you've gone out of your way to write bad code.
Even simply migrating the data might be a little traumatic - not insuperably so. In part, the complexity depends on which data types you use. (Character strings migrate easily; date and time values less easily, for example.) But migrating the applications would require a lot of work, as you say, unless you were extraordinarily prescient and wrote a really good data abstraction layer.
An upgrade to Informix SE 7.26 would be a no-brainer - get the software, install it, point it at your existing database. You'd probably want to recompile your programs to use the more modern CSDK, but you could do that incrementally with care (two INFORMIXDIR values, one for the old code, one for the new).
An upgrade to Informix Dynamic Server (IDS) 11.50 would require you to export the data (DB-Export) from SE and import it (DB-Import) into IDS. This would be very simple too, once you have IDS up and running. Getting IDS up and running takes more effort than SE, but is not all that hard.
Clearly, my recommendation is to stay put with Informix. The decision is yours, of course.
IDS is very closely related to SE, but they are different. IDS provides an almost strict superset of SE functionality. The places I can think of where there are differences are primarily edge case stuff:
The main area that may cause issues is transaction management. IDS has unlogged, logged and 'LOG MODE ANSI' database, as does SE. In IDS, you are encouraged to use a logged database - that would be a strong recommendation. IDS provides atomic statements in a logged database - either the statement works as a whole or it fails as a whole. However, many SE applications are not written with transactions in mind. There are some things you can't do when there are transactions on the database, such as open a cursor for update outside the scope of a transaction. This is what tends to bite code migrating from SE to IDS. Also, you cannot lock a table except in a transaction, and you cannot unlock a table except by COMMIT or ROLLBACK.
How much of a problem this will be depends on what you were using in SE and how the programs were designed (if they were designed rather than thrown together). An IDS unlogged database and an SE unlogged database are very close - and you could migrate from one to the other. But IDS can do things (like replication) only when the databases are logged, and you should aim to be using logged databases.
However, the migration to CSDK 3.50 should be just a recompile unless you've managed to do some really excruciatingly awful things.
关于 Informix 消亡的谣言被严重夸大了。
通过对嵌入式代码的投资，转换到品牌 O 或品牌 S 所节省的任何明显的标价成本将很快消失在重新开发成本中。 这就是生活中的事实：我见过一些项目在重建上花费了 10 万美元以上，以节省每年 2 万美元的许可费用。 这钱花得不值当。
您会非常非常确定 RDBMS 的转变将提供一些您确实无法实现的东西，而坚持现有的东西。 因为风险（来自痛苦的经历 - 我与它进行了长期而艰苦的斗争）是，如果不倒退，你可能会花费大量的美元和时间只是在原地奔跑。
如果您要退后一步，从整体上审视您的问题，我认为您最好评估更新的、松散耦合的、与数据库无关的架构的可能性，而不是将一种嵌入式模型替换为另一种嵌入式模型。 这将为您提供更大的灵活性。
希望有帮助。
Rumours of Informix's demise are greatly exaggerated.
With the investment in embedded code that you have, any apparent sticker price cost saving to be had from switching to brand O or brand S would very quickly disappear in redevelopment costs. That's just a fact of life: I've seen projects burn $100K+ on redevelopment to save $20K p.a. in licensing. That's not money well spent.
You would want to be very, very sure that the switch of RDBMS was going to offer something you really couldn't achieve sticking with what you have. Because the risk (from bitter experience - I fought against it long and hard) is that you could spend a fortune in dollars and time just running on the spot, if not going backwards.
If you're going to step back and look at your problem holistically, I think you would be far better off evaluating the possibilities of newer, loosely coupled, database-agnostic architectures than swapping one embedded model for another. This would provide you much greater flexibility down the track.
Hope that helps.
多年来我们一直使用 GeneXus 支持 Informix DB。 Informix 是一个很棒的数据库，但是没有很多工具可以帮助以敏捷的方式进行构建。 我知道许多 Informix 商店只使用 GeneXus IDE 来构建 Web 应用程序和智能手机应用程序。 如果您还没有听说过 GeneXus，请查看一下。
We have been supporting Informix DB for years using GeneXus. Informix is a great DB but there are not a lot of tools around it to help build in an agile way. I know many Informix shops that only use the GeneXus IDE to build web apps and smart phone apps. If you have not heard of GeneXus, check it out.