Обновление Informix - перейти на Oracle, Sybase или остаться с Informix? - PullRequest
3 голосов
/ 30 марта 2009

Ранее я опубликовал вопрос, чтобы подтвердить нашу текущую (хотя и архаичную) версию Informix здесь:

Как вы идентифицируете версию Informix на Solaris?

(Спасибо Джонатану и RET за разъяснения)

Мы определенно планируем обновление, но сначала обсуждаем, имеет ли смысл переходить на Oracle или Sybase в это время. Что вы думаете об этом? Я считаю, что хотя все 3 RDBM имеют свою уникальность, все они должны по существу охватывать одну и ту же почву. Так как же решить, какую базу данных использовать?

Главное, что мне нужно знать, если мы обновим Informix (в настоящее время использую 7.13), нужно ли нам модифицировать наши встроенные программы sql C? Если нет, то имеет смысл придерживаться Informix. Потому что, если бы мы использовали Sybase / Oracle и т. Д., У нас было бы много работы по обновлению внутренних программ.

Но если переключение на другую базу данных может дать большую отдачу в сравнении, мы все равно рассмотрим это. Я с нетерпением жду вашего мнения.

Ответы [ 3 ]

4 голосов
/ 31 марта 2009

Слухи о кончине Informix сильно преувеличены.

При наличии вложенных вами встраиваемого кода любое очевидное снижение себестоимости наклейки при переходе на бренд O или бренд S очень быстро исчезнет из-за затрат на реконструкцию. Это просто факт из жизни: я видел, как проекты сжигают более 100 тысяч долларов США на реконструкцию, чтобы сэкономить 20 тысяч долларов США. в лицензировании. Это не хорошо потраченные деньги.

Вы хотели бы быть очень, очень уверены, что коммутатор RDBMS предложит что-то, чего вы действительно не можете достичь, придерживаясь того, что у вас есть. Поскольку риск (из горького опыта - я дрался против него долго и упорно), что вы могли бы потратить целое состояние в долларах и время просто бег на месте, если не идет в обратном направлении

.

Если вы собираетесь сделать шаг назад и взглянуть на свою проблему в целом, я думаю, вам было бы гораздо лучше оценить возможности более новых, слабо связанных, не зависящих от базы данных архитектур, чем менять одну встроенную модель на другую. Это обеспечит вам большую гибкость в будущем.

Надеюсь, это поможет.

4 голосов
/ 31 марта 2009

Я предвзятый наблюдатель (я работаю в 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 потребует от вас экспорта данных (DB-Export) из SE и импорта их (DB-Import) в IDS. Это также будет очень просто, если у вас есть IDS и работает. Настройка и запуск IDS требует больше усилий, чем SE, но это не так сложно.

Очевидно, я рекомендую оставаться на месте с Informix. Решение за вами, конечно.


При использовании IDS мы должны были бы внести изменения в код или просто перекомпилировать?

IDS очень тесно связаны с SE, но они разные. IDS предоставляет почти строгий расширенный набор функций SE. Места, которые я могу придумать, где есть различия, - это, в первую очередь, крайний случай:

  • SE имеет дополнительный синтаксис для CREATE TABLE для поиска файлов C-ISAM для базы данных; IDS имеет совершенно другой набор расширений. Основной CREATE TABLE такой же (хотя у IDS есть типы, которых нет у SE, например, VARCHAR), но украшения отличаются.
  • SE имеет функции CREATE AUDIT и DROP AUDIT, а IDS - нет (имеет другие средства аудита).
  • SE имеет базу данных START и базу данных ROLLFORWARD; IDS нет (восстановление и вход в систему IDS отличается).

Основной областью, которая может вызвать проблемы, является управление транзакциями. IDS имеет незарегистрированную, зарегистрированную и «LOG MODE ANSI» базу данных, как и SE. В IDS вам рекомендуется использовать зарегистрированную базу данных - это была бы сильная рекомендация. IDS предоставляет элементарные операторы в зарегистрированной базе данных - либо оператор работает как единое целое, либо как сбой в целом. Однако многие приложения SE не написаны с учетом транзакций. Есть некоторые вещи, которые вы не можете сделать, когда есть транзакции в базе данных, такие как открыть курсор для обновления вне области транзакции. Это то, что приводит к миграции кода с SE на IDS. Кроме того, вы не можете заблокировать таблицу, кроме как в транзакции, и вы не можете разблокировать таблицу, кроме как с помощью COMMIT или ROLLBACK.

Насколько серьезной будет эта проблема, зависит от того, что вы использовали в SE и как программы были разработаны (если они были разработаны, а не объединены). Незамеченная база данных IDS и незарегистрированная база данных SE очень близки - и вы можете перейти с одного на другой. Но IDS может делать вещи (например, репликацию) только тогда, когда базы данных зарегистрированы, и вы должны стремиться использовать зарегистрированные базы данных.

Тем не менее, переход на CSDK 3.50 должен быть просто перекомпилирован, если вам не удалось сделать действительно ужасные вещи.

1 голос
/ 02 декабря 2010

Мы годами поддерживаем Informix DB, используя GeneXus. Informix - отличная БД, но вокруг нее не так много инструментов, которые могли бы помочь в быстром построении. Я знаю много магазинов Informix, которые используют GeneXus IDE только для создания веб-приложений и приложений для смартфонов. Если вы еще не слышали о GeneXus, проверьте его.

...