Обновление Informix - перейти на Oracle, Sybase или остаться с Informix?

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

Как определить версию Informix в Solaris?

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

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

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

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


person KNewton    schedule 30.03.2009    source источник


Ответы (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 потребуется экспортировать данные (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 есть НАЧАЛЬНАЯ БАЗА ДАННЫХ и ROLLFORWARD DATABASE; IDS нет (восстановление и вход в IDS разные).

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

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

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

person Jonathan Leffler    schedule 30.03.2009
comment
Джонатан, я очень ценю ваш подробный отзыв по этому поводу. Мы действительно понимаем, что если мы перейдем на Oracle с Informix, у нас в руках будет довольно большой проект. В настоящее время у нас есть более 1000 программ C со встроенным sql. Придется ли нам с IDS вносить изменения в код или просто перекомпилировать? - person KNewton; 03.04.2009
comment
Джонатан, еще раз спасибо за подробный ответ. Хотя наш код C со встроенным sql не очень сложен - он был написан лет назад, и я бы сказал, что он более сложен. Наша команда администраторов баз данных встретилась с IBM, и нам все еще нужно встретиться с Oracle, чтобы иметь возможность полностью оценить наш выбор. - person KNewton; 05.04.2009

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

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

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

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

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

person RET    schedule 31.03.2009
comment
RET, спасибо за подробный отзыв. Нам сложно это определить - стоимость пребывания с Informix (для нас это включает лицензирование плюс обучение базам данных) по сравнению со стоимостью перехода в Oracle (у нас уже есть лицензия и опыт администрирования баз данных). Так что у нас определенно есть некоторые оценки впереди. - person KNewton; 03.04.2009
comment
Чтобы расширить вышесказанное, стоимость миграции на Oracle будет включать время разработки и ресурсы для миграции встроенных приложений sql. - person KNewton; 03.04.2009
comment
@KNewton: Итак, из любопытства, вы придерживались informix или перешли на другую базу данных? .. Если вы переехали, потребовались ли серьезные усилия, чтобы переписать код? - person Frank R.; 13.06.2011

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

person Dane Drotts    schedule 01.12.2010