Есть ли смысл, разрабатывая веб-приложение, конвертировать все данные в MySQL

Нет.

(если да, то как)

Вот именно, как ты собираешься конвертировать в MySQL например, триггеры?

да бы

изыди

Не делай, ни веб-ориентированное, ни MySQL. Не выиграешь ничего. Если только ради денег.

Не ради денег, а ради расширения функционала и доступности с мобильных устройств, этого требует специфика самого приложения. А БД, кстати, почти 7 гигов.

появилась задача сделать то же самое ПО, но исключительно веб-ориентированное

Имя сестра, имя! Какой язык\технология? Там есть адаптер\драйвер доступа к Interbase\Firebird? Если есть, то нафига мучить попу? Переносить базу с высокотехнологичного сервера в наколенную поделку? Особенности работы с Firebird тебе известны, вот и следуй по пути наименьшего сопротивления.

Имя сестра, имя! Какой язык\технология? Там есть адаптер\драйвер доступа к Interbase\Firebird?

Мало, где нет, вообще-то

Понятно, запутало вступление про программу на Делфи.

Дело как бы не в размере, а в фрагментации - напрягают только тормоза после множественных вставок-удалений. А остальное очень даже неплохо, имхо, смысла никакого в MySQL нет. Тем более или старую прграмму на новую БД переписывать или репликацию в новую БД делать. Не, нет смысла.

зы. И с IBExpert-а слазить на поделки совсем не тянет.

Веб будет, разумеется, на PHP.

Меня просто смущает то, что сейчас с системой работает ну 20-25 человек, а когда это будет веб, то там появится клиентский кабинет и количество пользователей возрастет до минимум 1 000 человек. Сейчас вся информация разбита на 3 крупные базы, одна из которых, постоянно активна на запись: пишутся события с аппаратуры каждые 3-5 сек.

Еще хочется сделать всякие там instant search аля omnibox в google chrome, НО... «птица» не поддерживает fulltext index, а это какбэ не очень воодушевляет.

Веб будет, разумеется, на PHP.
разумеется

Толсто.

Тогда это другая задача, можно оставить старую базу и добавить новую MySQL, в которую вынести или продублировать данные с текстами, связать записи в базах по общему ID. Ну подключится к двум базам скрипт php вместо одной. LIKE ,вроде как, на мелких таблицах шустрее работает, чем fulltext - тут надо тесты сделать для начала.

зы. Если не секрет, что это за такая задача с аппаратурой и текстами одновременно ?

Firebird vs. PostgreSql

Вот это каким-то боком еще можно рассматривать. Но сабж вообще ни в какие ворота.

Думал об этом. Как всегда, хочется максимально «простой» способ. Ну, чисто программерская лень. Понятно, что совсем просто не выйдет.

А аппаратура: от gps-черных ящиков до охранных систем со вспомогательными темперами и прочей хренью. Это еще отдельная тема будет.

Возможно, не спорю. В чем-то вы абсолютно правы, но я с Postgre ни разу не работал, поэтому буду рад, если приведете сравнение.

Не пойми превратно, если есть возможность оставить данные в неприкосновенности — так и надо делать.

А с выбором mysql/postgesql всё просто — последний более универсален и предсказуем.

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

mysql же, AFAIR, теперь филиал корпорации зла.

Если у вас там не супер сложные данные со встроенными функциями и прочими advanced фичами то в чём проблема сделать дамп SQL (mysqldump в MySQL, незнаю как там в firebird). И потом импортировать хоть куда. Это же всё (MySQL, PostgreSQL) - SQL серверы удовлетворяющие (по большей части) стандарту. Можно сделать абстракцию от DB в виде класса который может работать с любым SQL сервером. Такого много есть - типа PDO, в PEAR какие то пакеты. Можно потом протестировать производительность с разными базами данных. Расскажите что за FireBird вообще? Никогда не слышал что бы его использовали для web приложений. Наверное он предназначен для чего то другого.

Учитывая:

А БД, кстати, почти 7 гигов.

количество пользователей возрастет до минимум 1 000 человек.

Сейчас вся информация разбита на 3 крупные базы

пора батенька архитектуру менять и новый слой заводить. Почитай про WSDL, REST и прочее. Определись с новой архитектурой. Сформируйте API. Реализуйте его начиная с минимума для Web-клиентов оставаясь на птице. Начинайте переносить старые клиенты на новый подход. И уже только потом смотрите какие БД вам будет лучше подходить по тестам.

Firebird - это изначально СУДБ для ПО разработанного на базе Borland Delphi. Если в кратце, то для десктопных ПО хорошая СУБД: переносимая, быстрая, поддерживающая кросс-БД транзакции и БД в одном файле до 64 Тб.

Основная проблема в том, что база, которая есть сейчас это три файла суммарно 7 гигов + 8-9 гигов, которые используются для журналирования событий аппаратуры.

А задача состоит в том, чтобы боль в жопе - при развертывании новой системы на базе старой БД - была как можно меньшей.

Дело в том, что в базе есть транзакции, которые обращаются не прямо к таблицам и строкам, а через субтранзакции. Т. е. есть целые таблицы целиком состоящие из «ссылок» на другие таблицы и данные.

Дело в том, что в базе есть транзакции, ...

Ну и что? Работаете вы всё равно с сущностями. Ещё раз говорю, заведите дополнительную прослойку. Через которую и будете обрабатывать данные как сущности. И тогда клиенту будет не важно, где и как хранятся данные. А там, хоть в 10-ти БД храните ваши данные, будет один центр их обработки. В последствии это позволит более детально подойти к оптимизации серверной части, без ущерба к работоспособности всей системы в целом.

http://ru.wikipedia.org/wiki/Model-View-Controller

А сейчас БД устраивает полностью ?

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

БД сложна. Хотя, может быть, я так говорю потому, что опыта со времени разработки стало больше и работа 5 лет давности выглядит для меня как поделка «на коленке».

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