Спасибо всем за ответы. Продолжаем разговор :)
1) Баги. Я думаю, про баги говорить особо смысла нет, их поправят как только желающие занесут в трекер... ну, с некоторым лагом, естественно :) 2) Legacy/ Про legacy подход действительно правильный - заточились на 1.5, работайте на 1.5, в чем вопрос-то. Более того, единственно возможный для развивающегося продукта. 3) По замечаниям Tonal >Админские: не очнеь понятно, почему это проблемы "админа". Проблемы с производительностью и надежностью системы (не только базы), возникающие на стадии эксплуатации, не обязательно порождены админом. Далее, я бы предложил смотреть на 2.5 в качестве текущей версии по фичам. >1. Мультипроцессорность (обещают) 2.5, 3.0, да и сейчас неплохо работает, не жалейте RAM. >2. Кластеризуемость (нет) Слишком широкое понятие. Но согласен, есть 2 момента - failover кластеризация и кластер для повышения производительности. Что нужнее (вопрос ко всем)? >3. Репликация (нет) Есть, есть :) FBReplicator, IBReplicator, Microtec CopyCat и др. > 4. Мониторинг производительности (начало решатся в 2-ке) А что бы тут хотелось? >5. Ручное обновление статистики индексов. ok >6. Ограничение длинны имён А откуда вылезло такое пожелание? Автогенеримые имена? ... >Програмёрские: >1. Отладка/трассировка сохранёнок и тринггеров. TraceAPI? FBScanner CE? MON$? Почему комбинация не удовлетворяет? >2. Ограничение длинны имён. повтор, см выше. > 3. Ограничение длинны списка в выражении IN (1500) Хорошая шутка :) >4. Отсутствие параметров в выражении IN (... where T.ID in (:list) где >:list - список). Эмулируется сохранёнкой. Тоже ничего :) >5. Нет прямой возможности узнать домены результата запроса (select >cast(1 as D_BOOL)...) из за этого приходится вручную следить за >соответствием типов. А как бы хотелось? Интерпретатор, который тип вроде Variant возвращад с RTTI? >6. Пользовательские агрегатные типы данных (например структурированный >адрес). Приходится вставлять группу полей во все таблицы и следить за их >согласованием. Зависит от реализации. >7. Наследование таблиц. Есть несколько рукопашных схем реализации. Не видно смысла. ИТОГО, проблемы не слишком то большие. Притерлись и привыкли :) Теперь перейдем к хотелкам. Давайте конкретные хотелки, по работе, так сказать. Без ограничений фантазии, но только своей фантазии, а не маркетологов. Только большая просьба не предлагать посмотреть feature matrix серверов вроде Oracle или MSSQL и настаивать на реализации всего списка. Именно так тонны бесполезных фич кочуют из одного сервера в другой. Мне вот хочется возможность писать и подключать плагины для подключения собственной реализации индексов :) Опять же, прошу вышеуказанных лиц воздержаться от комментариев. С уважением, Алексей Ковязин
