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

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

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

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

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

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

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

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

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

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