В Ubuntu 10.10 firebird2.5-classic_2.5.0.25920~ReleaseCandidate2.ds2-8_i386.deb лежит пока.

> Для оптимистов Firebird: Я уже с десяток баз сделал на разных движках и OS.

все пали ниц просто.

Пример: После портирования базы на MySQL в Oracle...

дальше это говно не читал.

Подпишусь под этим

Подпишусь под этим. И от себя добавлю, что у нас в стране много контор делает ПО на dbf/mdb(Access). Вот где настоящий ужас и таких приложений сотни особенно в гос учреждениях. А вы говорите Postgresql. Во многих случаях это уже избыток. У меня 6 лет 1.5 полет нормальный, а xml файлы формирует клиент с tinyXML. Вспомнилось: если вы все штатские такие умные, то почему в столовую строем не ходите

>> Без InnoDB не обойтись?

А в чём проблема?

Пропадают все прелести легкой и быстрой на чтение базы.

Любимый select count(*) вдруг начинает тормозить, ibdata пухнет, исчезают полнотекстовый поиск и индексы… Короче, шустрое read-mostly нетранзакционное хранилище превращается в подобие RDBMS. А зачем нужно не очень шустрое и так себе совместимое со стандартами подобие, когда есть нормальные СУБД?

А зачем нужно не очень шустрое и так себе совместимое со стандартами подобие, когда есть нормальные СУБД?

заменять firebird, например. где файлы пухнут гораздо интенсивней т.к. версии от версионности хранятся прямо в вайлах данных, а не как у innodb в отдельном undo. где полнотестого поиска вообще нет. где нет SMP, лога транзакций и кша SQL запрсов и не адекватный Read Commited.

Согласен postgresql лучше firebird. Как пушка лучше рогатки. Но что вы будете делать с пушкой при борьбе с воробьями. Да FB не идеален (тут почему-то ни один из хаятелей не сказал что структуру таблицы можно менять только 256 раз а потом обязательно бекап/ресторе). Но у него есть embeded версия размером в 5Мб. У него база данных просто файлик, который можно забрать или переместить (при выключенном сервере). Ведь мы говорим о SQL сервере локальной сети организации с несколькими сотнями сотрудников, а не о WEB с миллионом подключений. По размеру - у FB есть сборщик мусора, который неплохо справляется.

> где файлы пухнут гораздо интенсивней Мимо.

где полнотестого поиска вообще нет

Первая правда в топике. Правда, кому он нужен, подключают сфинкс и не парятся.

где нет SMP

Чукча новость не читатель?

нет ... лога транзакций ... не адекватный Read Commited.

А, понятно. Чукча вообще не знает, что такое СУБД вообще и версионные СУБД в частности; ну не разобрался в паре параметров транзакций топика до кучи.

(тут почему-то ни один из хаятелей не сказал что структуру таблицы можно менять только 256 раз а потом обязательно бекап/ресторе).

Вообще-то принято включать голову перед тем как создавать таблицу, чтоб не переделывать ее 256 раз.

Ведь мы говорим о SQL сервере локальной сети организации с несколькими сотнями сотрудников, а не о WEB с миллионом подключений.

Миллион одновременных подключений не выдержит ни одна существующая СУБД.

Как на чёт того что это может быть тестовая бд?

А никто и не говорит, что FB идеальный вариант. У меня к нему претензий хватает. Но он работает много лет, и есть не просит. Нареканий на его работу нет. На момент выбора СУБД он был очень хорошим вариантом, хотя сейчас лучше, безусловно, Постгресс или ДБ2

Firebird

Еще для него есть IBExpert.

Paradox неплохая вещь для своего времени. Мне кажется развитие Paradox закончилось правда еще на 7 версии и корел ни привнесла в него ничего, кроме иконок.(Судя по скорости выполнения запросов и инструментарию)

чукча то писатель, а тебе стоит разобраться, что такое класик и суперсервер архитектуры ФБ. тогда будет понятно какой офигительный прорыв в плане SMP у 2.5 с его суперкласик архитектурой (курам насмех).
для версионника Read Commited у ФБ мягко говоря странный получился, я бы даже сказал кривой. у любого другого версионника на RC обеспечивается statement level consistency, у ФБ же нифига неь обеспечивается, прямо как у голимого блокировочника.

> чукча то писатель, а тебе стоит разобраться, что такое класик и суперсервер архитектуры ФБ. тогда будет понятно какой офигительный прорыв в плане SMP у 2.5 с его суперкласик архитектурой (курам насмех).

О. Пошла конкретика. Действительно рад.

Так что ж не так с суперкласиком? В смысле, в каком месте он делает «не то»? Желательно либо ссылкой, либо воспроизводимым примером.

для версионника Read Commited у ФБ мягко говоря странный получился, я бы даже сказал кривой.

А что в нем не так? Серьезно.

у любого другого версионника на RC обеспечивается statement level consistency, у ФБ же нифига неь обеспечивается, прямо как у голимого блокировочника.

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

> Как на чёт того что это может быть тестовая бд?

Это о 256 изменениях? Ну, так тестовой БД не жалко раз на месяц и бекап-рестор сделать; чай не продакшн 24х7. Заодно можно узнать какие косяки в метаданных есть.

К сожалению, проект загибается, похоже. С перешел на постгрес с птички, и не жалею, вопреки всем визгам о «тормознутости» постгри, она гааааараздо, на порядки (в рамках моих задач) быстрее и удобнее.

>Так что ж не так с суперкласиком? В смысле, в каком месте он делает «не то»? Желательно либо ссылкой, либо воспроизводимым примером.

архитектура там кривая, совсем кривая. в любом нормальном сервере бд все коннекции могут воспользоваться единым буферным пулом (кешем).

А что в нем не так? Серьезно.

отсутствие statement level consistency

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

это вам показалось. мутация не зависит от версионности/блокировочности, она зависит от наличия row level тригеров. любая субд имеющая row level тригер может столкнуться с эффектом мутации. далее субд деляться на убогие, как ФБ, которые не реагируют на мутацию и позволяют писать мутирующие данные и на правильные, которые имеют механизмы защиты. вот оракл, например, субд правильная, т.к. имеет ДОПОЛНИТЕЛЬНЫЙ функционал, который выплевывает эксепшен. ФБ такого функционала не имеет и не реагирует на мутации.

PostgreSQL/MS SQL/Oracle vs Firebird

ага

да, точно, DB2 забыли

> PostgreSQL/MS SQL/Oracle vs Firebird ... DB2 забыли

Нормальное явление. Сперва набегают пионеры, которые знают только мускуль + пхп, а после того, как их отшивают, подтягиваются более адекватные люди. Правда, с несколько завышенными ожиданиями (соответственно уровню oracle/db2).

архитектура там кривая, совсем кривая.

Не являюсь специалистом в архитектуре СУБД, потому и попросил ссылку либо пример кривизны. На такой пример разве что «ровная, совсем ровная» могу ответить.

это вам показалось. ... ФБ такого функционала не имеет и не реагирует на мутации.

Вот как раз яркий пример того, что я писал в первом абзаце. Человек привык к возможностям и нюансам oracle и другую реализацию не воспринимает вообще, или же воспринимает в штыки.

P.S. Хотя лично мне логически нифига не понятно, как невозможность поменять значение поля в тригере не только можно называть нормальной и правильной, но еще и доказывать, что смена значения в тригере есть неполноценностью СУБД.

Не являюсь специалистом в архитектуре СУБД, потому и попросил ссылку либо пример кривизны.

http://www.sinatica.com/blog/en/index.php/articles/firebird-superserver-class...
теперь сравните с тем как выглядят архитектуры mysql, postgres, oracle

Вот как раз яркий пример того, что я писал в первом абзаце. Человек привык к возможностям и нюансам oracle и другую реализацию не воспринимает вообще, или же воспринимает в штыки.

дык, если было бы чего встречать, этом можно было бы меня обвинить, но в ФБ же никакой реализации нет. вы явно не понимаете, что такое мутация. почитайте оракловую доку, там очень понятно разжеванно. если на пальцах: тригер который обращается к той же таблице, что меняет DML вызвавший этот тригер видит недомодифицированую таблицу (мутирующую). DML уже часть строк изменил, часть еще нет. ФБ же не заморачивается на такие тонкости, оракл наоборот имеет ДОПОЛНИТЕЛЬНЫЙ функционал который не дает наступить на яйца разработчику.

> firebird embedded, аналога которому у постгреса и мускуля просто нету

Есть Embedded MySQL

>>Не являюсь специалистом в архитектуре СУБД, потому и попросил ссылку либо пример кривизны.

http://www.sinatica.com/blog/en/index.php/articles/firebird-superserver-class...

теперь сравните с тем как выглядят архитектуры mysql, postgres, oracle

Как раз это я более-менее знал; интересовал именно момент, что здесь плохого и как надо хорошо. Особенно в свете того, что описанные решения держат пару сотен одновременно работающих пользователей на среднем железе особо не напрягаясь. Для справки фанатам мускуля - их «стотыщмульенов одновременных пользователей сайта» значат в лутшем случае те же пару сотен одновременных подключений (в базу данных конечно).

дык, если было бы чего встречать, этом можно было бы меня обвинить, но в ФБ же никакой реализации нет. вы явно не понимаете, что такое мутация.

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

Только вот беда - не получалось за последние 5-6 лет получить отсутствием мутаций в ФБ ниже пояса. Пример. Есть DML, который модифицирует таблицу. Есть 2 тригера before insert и один after insert. В before insert я пишу что-то навроде

if new.somefield is null then select some_value from some_table into new.somefield;

В другом before insert пишу что-то типа

new.anotherfield new.somefield * some_another_value;

А после вставки соответственно

insert into log_table (first, second) values (new.somefield, new.anotherfield);

Теперь собственно вопросс - или я нифига не понял и все вышеописанное так же примитивно реализуется на оракле, или же я ничего не понимаю и оракл заботясь обо мне не даст мне такое сделать, потому что лутше меня знает что мне надо. Но если нельзя и очень хочется, то мне нужно будет (здесь долгий список последовательности стучаний по всяким штукам). Я правильно понимаю?

И нашел, наконец, что вы имели в виду под неправильной реализацией read commited и отсутствием statement level consistency. Это когда тарнзакция читает закоммиченные данные, оказывается :)))

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

http://www.sql.ru/forum/actualthread.aspx?tid=173455&pg=2

http://rsdn.ru/forum/db/573511.aspx

Если кратко суть - read commited - значит, как ни странно, «прочитать закоммиченное». Не нравится такая формулировка, прочитай документацию и стартуй снапшот. Или пользуй другой сервер, тут кому что больше нравится.

Есть Embedded MySQL

В свете предыдущих высказываний по теме вспоминать про mysql, даже embedded, как-то неспортивно. Не находите?

Как раз это я более-менее знал; интересовал именно момент, что здесь плохого и как надо хорошо.

нужно как планируют в 3.0 - единый кеш на все конекции. т.е. то что в mysql 3.x уже было. а держать конекции много ума не нужно, нужно эффективно обслуживать эти конекции.

if new.somefield is null then select some_value from some_table into new.somefield;

если в some_table 3 записи у вас фигня получиться, но допустим вы имели ввиду
if new.somefield is null then select sum(some_value) from some_table into new.somefield;
и тригер вызывает update по всей таблице some_table

то на ФБ этот SUM при срабатывании на второй записи увидит some_table которую уже покарежило первое срабатывание, но еще не покарежило последнее. т.е. фигню какую-то увидит, терменами оракла мутирующую таблицу.
кроме этого хрень в том что update может вызывать тригер в разном порядке, может в порядке записей 123, может 321, на усмотрения оператора. соответственно ты на одном и том же наборе some_table до обеда можешь получить один результат отработки тригера, а после обеда другой, просто по тому, что оптимизатор чуть другой план выбрал под апдейт.

Если кратко суть - read commited - значит, как ни странно, «прочитать закоммиченное».

все, абсолютно все версионники обеспечивают на уровне RC гораздо больше чем «прочитать закоммиченное»

ЗЫ. http://rsdn.ru/forum/db/573511.aspx

этот косяк с RC не связан, на снепшоте те же яйца.

> нужно как планируют в 3.0 - единый кеш на все конекции. т.е. то что в mysql 3.x уже было. а держать конекции много ума не нужно, нужно эффективно обслуживать эти конекции.

Об чем и речь - ФБ довольно еффективно обслуживает клиентов. Только он делает это не так, как привыкли пользователи других СУБД. Странно только что это представляется как минус в сторону ФБ. А суперклассик является архитектурой, на базе которой разрабатывается 3.0, который в свою очередь по вашим словам будет более правильным - это тоже плохо?

то на ФБ этот SUM при срабатывании на второй записи увидит some_table которую уже покарежило первое срабатывание, но еще не покарежило последнее. т.е. фигню какую-то увидит, терменами оракла мутирующую таблицу.

Нифига не понял. Есть таблица sometable с полем somefield. В ней три записи из значениями somefield (1, 2, 3). Триггер на вставку в эту таблицу содержит такой текст:

if (new.somefield is null) then begin

update sometable set somefield = 1;

select sum(somefield) from sometable into new.somefield;

end

В результате после вставки все значения поля somefield равны 1, нововставленное равно 3. Внимание, вопросс - что здесь неправильно? То, что такое поведение в руках идиота-пользователя может привести к непредсказуемым результатам? Ну, это проблемы идиота-пользователя.

все, абсолютно все версионники обеспечивают на уровне RC гораздо больше чем «прочитать закоммиченное»

Не все; не будьте столь категоричны. И это не повод требовать того же от остальных - только на том основании, что вы привыкли к этому в «привычном версионнике».

ЗЫ. http://rsdn.ru/forum/db/573511.aspx

этот косяк с RC не связан, на снепшоте те же яйца.

Честно говоря, сам виноват - не ту ссылку скопировал. Но так может и лутше. Этот косяк - один из исправленных, о чем говорилось раньше. Тред немного староват; вы, вижу, тоже не заметили :)

Честно говоря, сам виноват - не ту ссылку скопировал. Но так может и лутше. Этот косяк - один из исправленных, о чем говорилось раньше. Тред немного староват; вы, вижу, тоже не заметили :)

ошибаетесь, косяк этот здравствует и по ныне и нет никаких шансов, что он будет исправлен в 3.0. кстати зовется косяк cusrsor stability. имхо именно он и требует исправления в первую очередь.

А суперклассик является архитектурой, на базе которой разрабатывается 3.0, который в свою очередь по вашим словам будет более правильным - это тоже плохо?

нет, это не плохо, это хорошо. плохо то, что архитектура 3.0 не была сделана 10 лет назад, ведь основные конкуренты уже лет 10 имеют такую архитектуру которую ФБ только планирует заиметь. почему это важно, да потому, что это цепляет остальные компоненты. в первую очередь оптимизатор. сейчас ФБ полагается на кеш файловой системы, содержимое которого для субд черный ящик. а оптимизаторы взрослых субд очень многие решения принимают именно на основе данных из кеша. например если известно, что 90% страниц таблицы sometable в кеше фулсканить таблицу не оптимально.
т.е. когда ФБ наконец обзаведется сравнимой с остальными архитектурой остальные уже будут иметь навороченный оптимизатор, навороченную и/о (всякие readahead, многоблочное чтение), отлаженную десятилетиями SMP. вот это плохо.

по мутации у тебя снова не удачный пример.
http://www.interface.ru/fset.asp?Url=/oracle/ora7/ora7a08.htm

попробуй на ФБ прогнать пример из рисунка 8-1, наглядно увидишь от чего пытается защитить оракл.

> ошибаетесь, косяк этот здравствует и по ныне и нет никаких шансов, что он будет исправлен в 3.0. кстати зовется косяк cusrsor stability. имхо именно он и требует исправления в первую очередь.

Нашел. http://sql.ru/forum/actualthread.aspx?tid=748785

Я и говорю - некоторые частные случаи УЖЕ пофиксены (a = b, b = a - как пример); некоторые существуют только в головах тех, кто привык к другому поведению.

плохо то, что архитектура 3.0 не была сделана 10 лет назад, ведь основные конкуренты уже лет 10 имеют такую архитектуру

Простите, у кого в 2000 году была «такая» архитектура? И самое главное - почему отсутствие вышеупомянутой архитектуры не мешает ФБ делать свою работу?

по мутации у тебя снова не удачный пример.

http://www.interface.ru/fset.asp?Url=/oracle/ora7/ora7a08.htm

попробуй на ФБ прогнать пример из рисунка 8-1, наглядно увидишь от чего пытается защитить оракл.

Прогнал. Опять никаких проблем. Могу выложить DDL скрипты для подтверджения, поскольку здесь писать долго. Но результат почему-то не удивил - select max(somefield) в триггере before update для «мутирующей» в терминах оракла таблицы вивел в внешнюю таблицу именно максимальные значения, которые были в модифицируемой таблице до начала апдейта. И с этой фигней оракл не может справится без дополнительных подпорок? Впечатлен.

выкладывай, посмотрим.

Ну, вот.

CREATE GENERATOR GEN_logtable_ID;

CREATE TABLE logtable (
    ID           INTEGER NOT NULL,
    logvalue     INTEGER
);

SET TERM ^ ;

CREATE OR ALTER TRIGGER logtable_BI FOR logtable
ACTIVE BEFORE INSERT POSITION 0
as
begin
  if (new.id is null) then
    new.id = gen_id(gen_logtable_id,1);
end
^
SET TERM ; ^

CREATE GENERATOR GEN_mutable_id;

CREATE TABLE mutable (
    ID        INTEGER NOT NULL,
    one_id    INTEGER,
    two_id    INTEGER
);

SET TERM ^ ;

CREATE OR ALTER TRIGGER mutable_BI FOR mutable
ACTIVE BEFORE INSERT POSITION 0
as
begin
  if (new.id is null) then
    new.id = gen_id(gen_mutable_id,1);
end
^

CREATE OR ALTER TRIGGER mutable_BU FOR mutable
ACTIVE BEFORE UPDATE POSITION 0
as
begin
  insert into logtable(logvalue)
    select max(one_id) from mutable;
end
^

SET TERM ; ^

insert into mutable(one_id, two_id) values(1, 1);
insert into mutable(one_id, two_id) values(2, 2);
insert into mutable(one_id, two_id) values(3, 3);

update mutable set one_id = one_id * 2;

select id, logvalue from logtable;
id   logvalue
1    3
2    3
3    4

И да, что там с архитектурами СУБД в 2000-м году?

ну и какое отношение пример имеет к примеру что я тебя отослал по ссылке ?

И да, что там с архитектурами СУБД в 2000-м году?

там был SMP и единый кеш.

> ну и какое отношение пример имеет к примеру что я тебя отослал по ссылке ?

Предложение SQL исполняется для первой строки таблицы. Затем возбуждается триггер AFTER ROW. В свою очередь, предложение внутри тела триггера AFTER ROW пытается опросить первоначальную таблицу. Однако, поскольку таблица EMP мутирует, ORACLE не позволяет этот запрос. Поэтому возникает ошибка времени выполнения

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

там был SMP и единый кеш.

«Там» - это где? И как мешает топику их отсутствие?

ясно. в режиме дурки мне не интересно дискутировать. интересно разобраться, прогони пример.

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

ты продемонстрировал только то, что ФБ не имеет никаких механизмов защиты, но по каким-то религиозным соображениям не хочешь признать к чему такое отсутствие приводит. мне не понятно в чем проблема потратить 2 минуты на пример ...

Механизмов защиты от чего? От того, что в оракле до сих пор не могут реализовать примитивный функционал и придумали под это дело большую теорию?

К чему такое отсутствие приводит - какое отстутствие? Любой функционал может привести к катастрофическим последствиям. Недавно на скуль.ру ребята играли в игру «Уложи SQL-сервер простым запросом». И укладывали. Но это не значит, что уложенные сервера плохие - просто при работе с каждым из них надо соблюдать некоторые правила. Как с мутирующими таблицами в оракле. Черт, я уже оправдываю оракл перед ораклистом. Мдя.

И честно говоря позиция - «ты мне показал, что я был неправ, но теперь потрать две минуты чтобы прочесть мои мысли и доказать обратное а иначе все это дурка» слегка того - не находишь? Может, сам напишеш пример, который покажет что в ФБ есть то, чего там быть не должно?

Особенно в свете того, как ты слил вопросы о конкурентах с SMP в 2000-м году; с единым кешем; с тем, каким боком все это нужно ФБ; с багами... Хм. Кажется, я последние пару постов начинаю повторятся.

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

Хм. Интерессно, а умные ораклоиды на форумах общаются?

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

Если смотреть на проблему шире, то любой многострочный select без order by выдаст неопределенную информацию в плане - какая запись будет первой и в какой последовательности они будут получены. Что же и при этом исключение генерировать?

Как дела с мутирующими таблицами в других СУБД: DB2, PostgreSQL и прочие.