Обновление Informix-перейти на Oracle, Sybase или остаться с Informix?
Ранее я опубликовал вопрос, чтобы подтвердить нашу текущую (хотя и архаичную) версию Informix здесь:
Как вы определяете версию Informix на Solaris?
(Спасибо Джонатану и РЭТУ за то, что прояснили это)
Мы определенно планируем модернизацию, но сначала обсуждаем, имеет ли смысл перейти на Oracle или Sybase в это время. Каково Ваше мнение на этот счет? Я считаю, что, хотя все 3 СУБД имеют свою собственную уникальность, они должны по существу, все они охватывают одну и ту же территорию. Так как же решить, какую базу данных использовать?
Большой кикер заключается в том, что мне нужно знать, если мы обновим Informix (в настоящее время используется 7.13), потребуется ли нам модифицировать наши встроенные программы sql C? Если нет, то имеет смысл придерживаться Informix. Потому что если бы мы пошли с Sybase/Oracle и т. д., У нас было бы много работы по обновлению внутренних программ.
Но если переключение на другую базу данных может предложить большую отдачу по сравнению тогда мы все-таки рассмотрим его. Я с нетерпением жду вашего мнения.
3 ответа:
Я предвзятый наблюдатель (я работаю в IBM на Informix) - относитесь к моим комментариям с должной осторожностью.
Если ваши приложения написаны на Informix ESQL/C, вам придется сделать серьезную операцию, чтобы переместить их в другие системы. Вам нужно будет решить, какой альтернативный интерфейс использовать - ваш кросс-платформенный выбор (с C в качестве базового языка) - ODBC, но Oracle предоставляет OCI, а Sybase предоставляет TDS в качестве альтернативы.
Напротив, с Informix ESQL / C, обновление до текущая версия (Informix с ClientSDK 3.50, содержащих языке esql/с 3.50, на которых составляет более поздней, чем на языке esql/с 6.00, которую вы в настоящее время используют) должно быть безболезненным, если вы вышли из своего пути, чтобы написать плохой код.
Даже простая миграция данных может быть немного травмирующей - но не непреодолимой. Отчасти сложность зависит от того, какие типы данных вы используете. (Символьные строки переносятся легко; например, значения даты и времени переносятся менее легко.) Но миграция приложений будет требуется много работы, как вы говорите, если только вы не были чрезвычайно прозорливы и не написали действительно хороший слой абстракции данных.
Обновление до Informix SE 7.26 будет простым делом-получите программное обеспечение, установите его, наведите на существующую базу данных. Вы, вероятно, захотите перекомпилировать свои программы, чтобы использовать более современный CSDK, но вы можете сделать это постепенно с осторожностью (два значения INFORMIXDIR, одно для старого кода, одно для нового).
Обновление до Informix Dynamic Server (Идентификаторы) 11.50 потребуется для экспорта данных (БД-экспорт) от SE и импортировать его (ДБ-импорт) в ИД. Это было бы очень просто, как только у вас есть ID и работает. Чтобы получить ID и запустить его, требуется больше усилий, чем SE, но это не так уж сложно.
Очевидно, что моя рекомендация-оставаться на месте с Informix. Решение, конечно, за вами.
С IDS, нам придется вносить изменения в код или просто перекомпилировать?
IDS очень тесно связан с SE, но они разные. IDS обеспечивает почти строгий набор функций SE. Места, о которых я могу думать, где есть различия, - это в первую очередь материал edge case:
- SE имеет дополнительный синтаксис для создания таблицы для размещения файлов C-ISAM для базы данных; IDS имеет совершенно другой набор расширений. Базовая таблица CREATE та же (хотя IDS имеет типы, которых нет у SE, такие как VARCHAR), но украшения разные.
- SE имеет создание аудита и падение аудит и идентификаторы не имеет (имеет другие средства аудита).
- SE имеет стартовую базу данных и базу данных ROLLFORWARD; IDS - нет (восстановление и вход в систему IDS отличаются).
Основной областью, которая может вызвать проблемы, является управление транзакциями. Ids имеет незарег, регистрируется и базы режим журнала в формате ANSI, а не ЮВ. В IDS рекомендуется использовать зарегистрированную базу данных-это будет хорошей рекомендацией. IDS предоставляет атомарные операторы в зарегистрированной базе данных - либо оператор работает как целое, либо она терпит неудачу в целом. Однако многие приложения SE не пишутся с учетом транзакций. Есть некоторые вещи, которые вы не можете сделать, когда есть транзакции в базе данных, например, открыть курсор для обновления вне области транзакции. Это то, что имеет тенденцию кусать код, мигрирующий из SE в IDS. Кроме того, вы не можете заблокировать таблицу, кроме как в транзакции, и вы не можете разблокировать таблицу, кроме как путем фиксации или отката.
Насколько это будет проблематично, зависит от того, что вы использовали в SE и как были разработаны программы (если они были разработаны, а не скинуты вместе). Базы данных IDS unlogged и SE unlogged очень близки - и вы можете мигрировать из одной в другую. Но идентификаторы могут делать такие вещи (например, репликацию) только тогда, когда базы данных зарегистрированы, и вы должны стремиться использовать зарегистрированные базы данных.
Однако миграция в CSDK 3.50 должна быть просто перекомпиляцией, если только вам не удалось сделать некоторые действительно мучительно ужасные вещи.
Слухи о кончине Информикса сильно преувеличены.
С инвестициями во встроенный код, которые у вас есть, любая очевидная экономия на цене наклейки, которую можно получить от перехода на бренд O или бренд S, очень быстро исчезнет в затратах на реконструкцию. Это просто факт жизни: я видел, как проекты сжигают $ 100 тыс.+ на перепланировке, чтобы сэкономить $20 тыс. в год на лицензировании. Это не очень хорошо потраченные деньги.
Вы хотели бы быть очень, очень уверены, что переключатель СУБД собирался предложить то, чего вы действительно не смогли бы достичь, придерживаясь того, что у вас есть. Потому что риск (по горькому опыту - я боролся с ним долго и упорно) заключается в том, что вы можете потратить целое состояние в долларах и время просто бегая на месте, если не идете назад.
Если вы собираетесь сделать шаг назад и взглянуть на свою проблему целостно, я думаю, что вам было бы гораздо лучше оценить возможности новых, слабо связанных, баз данных-агностических архитектур, чем менять одну встроенную модель на другую. Это обеспечит вам гораздо большую гибкость в дальнейшем.Надеюсь, это поможет.
Мы поддерживаем Informix DB в течение многих лет, используя GeneXus. Informix-это отличная БД, но вокруг нее не так много инструментов, которые помогут гибко строить. Я знаю много магазинов Informix, которые используют только IDE GeneXus для создания веб-приложений и приложений для смартфонов. Если вы не слышали о GeneXus, проверьте его.