Спецов найти трудно, кто использовал - хвалит. Для человека со стороны, наверное, будет трудно привыкать к ibm-овской модели хранимок. Да и вообще, "рядом стоявших" с айбиэмом у нас как-то нет. Если решение будет "чёрным ящиком", который стоит и работает, то один раз заплатить хорошему спецу, наверное, будет хорошим решением. А так - смотря что за процессинг. Если удастся свести использование к named users, то берите оракл.

Для начала я бы упомянул, что есть надёжность фактическая, а есть надёжность имиджевая. Решение на информиксе может быть и будет надёжным, но многие покупатели услышат слово, спросят "Что такое информикс?", услышат от своего айтишника что-нибудь типа "да была такая база лет пятнадцать назад" и уйдут навсегда.

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

В варианте же, допустим, "нормальный клиент с адекватным айтишником" в случае Oracle или DB2 мнения будут "Слышал, что что-то мощное / Да, на нём можно писать такие решения", в случае того же Firebird - "Никогда не слышал / Да, его не очень часто, но используют", а вот в случае Informix, к сожалению - "Никогда не слышал / Ну, я слово такое знаю, но только слово".

TerraInformixa, такое впечатление, что Вы при чтении не сумели отделить "слова клиента" от "слов айтишника".

Какой бы ни было, но, к сожалению, Informix на сегодня настолько не на слуху, что делать на нём систему на продажу - реальный риск, примерно так же, как на Clarion, Btrieve итп.

TerraInformixaНедостаток Информикса лишь в малой распространенности в России.
Я и не говорю, что у него есть другие недостатки. Я говорю, что для проекта "на продажу" этот недостаток прискорбно существенен.

miwaonlineНу, еще нормальный айтишник может пожать плечами и сказать что-то типа "Зависит от кривизны рук тех, кто писал софт, а не от используемой СУБД".
Нормальный рядовой айтишник так и скажет, а нормальный айтишник-начальник (к которому и пойдёт советоваться клиент) - уже нет. Потому что он, понимая, что это правда, понимает и другое. Вот здесь есть, допустим, Дима, про которого я поверю, что десятигиговая база на ФБ у него будет летать. Я мог бы свести его со своим знакомым, который говорит: когда база подползает к пяти гигам, мы советуем нашим клиентам раскошелиться на оракл, потому что на фб наше приложение начинает сильно тормозить. Я мог бы свести с другим знакомым, у которого приложение держит половину информации в блобах и обрабатывает на сервере приложений, потому как работа с этими данными реляционными методами в фб получается слишком медленной. Я верю, что при личном знакомстве Дима им всё покажет, и у них всё залетает. И тем не менее, на вопрос "потянет ли мсскл десятигиговую базу" я отвечу "да у всех тянет и стогиговые", а на вопрос "потянет ли фб десятигиговую базу" - выдам.. не столь уверенный ответ. Именно потому что потянет далеко не в каждых руках. И потому, что спрашивающего интересуют не мои философские рассуждения о руках, а измеримые основания "покупать" или "не покупать".

Dimitry SibiryakovИ будешь не совсем прав
Безусловно. Поскольку мы все понимаем и про руки, и про гигабайты. И всё же это куда ближе к тому, что хотел услышать клиент / стоит услышать клиенту. Если я буду жевать про руки, он в конце концов взбесится, скажет "от тебя никакого толка" и уйдёт. И в общем-то будет прав. Поэтому при решении вопроса "стоит ли исследовать эту систему глубже" имя, увы, будет иметь значение. А тем, кто пока с этим не согласен, предлагаю обдумать вопрос о приобретении системы на dBase II :)

Dimitry SibiryakovНу, ты можешь сделать фразу неподкопной
Лет пять назад я бы так и поступил, но в последние годы стал чаще выбирать краткость и яркость в ущерб формальной точности. Полностью мысль выглядит примерно так: "Клиенту я ответил бы более чем одной фразой, вполне точными, и суммарно создающими ощущение, аналогичное ощущению от этой одной фразы". Но сейчас я предпочту просто сказать эту фразу.

Dimitry SibiryakovМы сейчас говорим только о синхронной репликации, поскольку только она обеспечивает надёжность. Асинхронная репликация надёжность не обеспечивает.
Это слишком сильное утверждение. Хотя, конечно, вопрос в том, что именно понимать под надёжностью.

AndronЗа несколько лет эксплуатации Informix HADR ни разу при асинхронной репликации не терялись транзакции.
Под надёжностью можно понимать не только потери. Скажем, следующий апокалиптический сценарий:

- падает резервный сервер
- на основном идут изменения данных
- падает основной сервер
- поднимается резервный сервер
- на резервном идут изменения данных
- поднимается основной сервер
- на резерв приезжают изменения с основного сервера.

В результате в зависимости от реализации и специфики данных возможны разные не очень приятные вещи.

Dimitry SibiryakovИменно поэтому я и настаиваю на своём сильном утверждении. В этом сценарии надёжность пошла лесом уже в момент когда при одном упавшем сервере операции продолжили делаться на другом.
В самом деле, надёжность - понятие непростое. Делаешь-делаешь отказоустойчивый кластер, а оказывается, что он не надёжнее, чем одинокий сервер (если воспринять Ваше утверждение буквально, так даже вдвое менее надёжен).

В более близкой мне реальности, если сидит тысяча пользователей, ждущих возможности заработать компании денег, работая с системой, и стоит сервер, способный их обслужить, их таки надо обслужить. А если при этом айтишник должен разгрести репликацию так, чтобы в итоге получилась целостная база - так за это ему зарплату и платят, а не за фразу с умным видом "так делать нельзя".

Dimitry Sibiryakovи требования по сохранности информации не такие жёсткие...
Знаешь, про многих дба, которых я знаю, я про себя считаю, что они страдают синдромом узкого специалиста - в частности, абсолютизируют базу, не понимая, что ценностью обладает не база сама по себе, а база как инструмент решения тех или иных задач из реального мира. Я это к тому, что кроме "требований по сохранности информации" есть ещё требования по "соответствию информации реальности", в частности по "вводу информации в систему". Если система предназначена для обслуживания текущей деятельности, "устаревшая целостная база" ценности не имеет, и всё время пока она "устаревшая" смело можно заносить в "простой" с соответствующим минусом к "надёжности".