41
VARCHAR(32765). Как итог накладные расходы на селект выростают в 4 раза!!
По сравнению с другими БД.
А нам как раз нужно совершать огромное количество именно SELECT.
Невозможно себе позволить такие накладные расходы. БД Firebird не подходит
однозначно.
Лучшая по результатам линейных SELECT всегда была и остается MySql
обгоняя любые другие БД. MySql проигрывает почти всем при выполнении
сложных составных запросов, требующих промежуточных вычислений самой
БД, но в программах документооборота таких нет. По крайне мере всегда можно
согласиться в одном или двух местах на некоторое увеличение накладных
расходов, но это не будут постоянные и неоправданные расходы при всех
SELECT которые неизбежны с Firebird. Единственное преимущество Firebird в
том что на него можно возложить обработку запросов которые имеют данные
связанные между собой, но находящиеся в разных таблицах. В нем нет нет
хранимых процедур, триггеров и еще много чего. Но все это можно сделать
внутри приложения. Будет немного больше кода, но оно с лихвой окупается
малыми накладными расходами процессора, памяти, времени обработки в конце
концов.
Firebird необходим при массовой вставке записей, при работе с индексами,
файловое кэширование, коэф. сжатия записей, управление памятью сортировок,
но для документооборота это не используется.
Firebird применяется в основном для небольших и средних встраиваемых
приложений, то есть когда сервер ставится в комплекте какого-то приложения
(бухгалтерского или складско-учетного) и работает в "невидимом" для
пользователей режиме. Также можно отметить, что в крупных компаниях
Firebird в основном используется как "вспомогательная" база данных - когда
нецелесообразно ставить большую БД (с неизбежным администратором) в
небольшой филиал или удаленное подразделение, в этом случае в качестве
"заменителя" часто выбирают именно Firebird.
Оптимальным вариантом является MySQL. Данная программа не сильно
нагружает систему. Данная СУБД широко распространена, поэтому будет не
сложно найти того, кто сможет ее обслуживать