hvladЗаметил, стараюсь не реагировать... Но иногда так достаёт... :(


так есть здесь хоть один вменяемый опонент который без эмоций и пены у рта сможет ответить на несколько технических вопросов по интербейс ?

авторНо на моей памяти тут практически все сравнения с участием FB проходили под лозунгом "FB ацтой vs FB фарева", вместо того чтобы спокойно обсудить и взвесить достоинства и недостатки в контексте поставленных задач

очень сложно спокойно обсуждать что либо когда интелекта опанентам хватает только засрать весь форум. тема ibase мне совершенно не интерсна, но уж больно запарили фанаты которые по всему форуму предлагают ibase клоны как замену промышленым субд, мотивируя лишь матом.

1. в стандарте ANSI SQL есть фундаментальное требование по ACID, FB его злобно нарушает. например вот такой sql
delete from test
where test.ID in (select id from test GROUP BY id HAVING count(id)>1);
не удалит все записи, а удалит только дубли.

2. The Interbase optimizer was a cost-based optimizer with a
heavy emphasis of search tree pruning. Sometime in the
version 4 timeframe somebody thought they could improve
the optimizer with a few heuristic rules. He was wrong,
and substantially broken the optimizer.
http://sourceforge.net/mailarchive/forum.php?forum_id=6330&style=flat&viewday=23&viewmonth=200205

3. There is already basic multiprocessor support in the current version of Firebird, as it uses a standard process-based architecture. However, this means a single process is tied to a particular processor in an SMP system, irrespective of system load, and doesn't share memory. Firebird 3.0 will enable multiple threads to run across multiple CPUs at the same time, all sharing memory. This feature will allow enterprises to cut down on the amount of hardware needed for larger databases, according to Beach.

я так понимаю еше не было 2-го релиза, 3й релиз еще просто не зашедулен.

4. для mission critical апликаций нужен лог транзакций, в 21 веке заниматся вот таким нелепо:
http://www.ibase.ru/devinfo/doc_calford_1.htm

5. невостановимый бэкап
http://www.ibase.ru/devinfo/norestore.htm

6. Остановка во время сборки мусора

Когда исходный код Interbase был опубликован, оказалась выявлена еще одна неприятная особенность, которая может привести к серьезным повреждениям базы данных. Если во время принудительного завершения работы сервера (gfix -shut ...) были активные подключения и сервер занимался сборкой мусора (работал sweep thread), то база данных может быть (и чаще всего это так) повреждена.
Уменьшить вероятность таких повреждений можно только отключив автоматическую сборку мусора (gfix bd.gdb -housekeeping 0), а в случае принудительной сборки мусора (gfix -sweep) предварительно делать "быстрый" backup (gbak с ключом -g), чтобы резервная копия базы данных оказалась самой свежей в случае сбоя и повреждения БД.

В Yaffil эта проблема исправлена.
http://www.ibase.ru/devinfo/db_repair.htm#corrupt

7. Транзакции: Где они живут
Транзакции живут на сервере, а стартует их всегда только клиентское приложение. В триггерах и процедурах стартовать и завершать транзакции невозможно.
http://www.ibase.ru/devinfo/ibtrans.htm

собственно вопрос у меня такой: не кажется ли вам что для начала нужно исправить вот такие архитектурные косяки и только потом обсуждать убогость mysql, скорость mssql и т.д. и т.п. ?

nik_x
А помимо научно-белетристической литературы про IB, больше не судьба

т.е. озвученых косяков нет, на ibase.ru биллетристика, а разработчики вообще чушь несут, я правильно понял ?

hvladACID - основополагающие требования, без них действительно трудно называться транзакционной СУБД. И IB\FB их нигде не нарушают.

а можно просветить неуча в какое консистентное состояние приведет чудо-сервер
insert into a select * from a ;