Senya_LЗаинтересовала одна тема в другой ветке. Интересен опыт работавших как с Firebird, так и Postgres. Какие преимущества и недостатки у этих РСУБД? Сам работал только с Firebird.
багофича со стабильностью курсора, отсутствие SMP (класик это не серьезно), лога транзакций, кеша SQL запросов и еще нескольких базовых вещей в ФБ делает затруднительным сравнение в лоб. это разного порядка субд под разные задачи ...

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

ЗЫ. обратите внимание на фокспро, вам должно жутко понравится !

Senya_Lа вы работали с Firebird, Postgres и Foxpro?

приходилось. вместо постгрес с его клоном enterprisedb (его теперь postgres plus)

kdv
Думаю, что даже через пару лет, после ФБ 2.5 в НГ и 3.0, он так и будет вспоминать слова из той старой песни.
а что есть планы в ближайшую пятилетку что-то изменить координально ? будут ли модификации с подзапросами запускатся в отдельной транзакции ? а что с серверными курсорами ?

2Senya_L

ООП в субд не нужно, думаю это так фичу с вложеными таблицами называют. из нужных мне фич в постгрес плюс были рекурсивный SQL, пакеты, ref_cursors, партитионинг, rownum, псевдотабличка dual. в обычный постгрес эти фичи портируются с задержкой посему не вкурсе что из этого уже перенесено.

FreemanZAVЯ бы сравнивал в первую очередь эффективность сборки мусора, просмотр версий и т.п.
+1, но там реализация версионности по сути одинакова, версии прямо в страницах данных напиханы, единственно ФБ умудрилось READ COMMITED с неконсистентным чтением реализовать (на сколько я знаю единственный из версионников)

2LeXa NalBat
в постгрес плюс connect by prior сделан, левый патч для этой фичи еще к семерке существовал.

2Senya_L

пакеты это что-то типа схем (к стате тоже хорошая фича пострес) но для кода, сильно помогает девелоперам. rownum - нумерует строки в текущем наборе, считай это сильно навороченый вариант LIMIT из mysql.

2Gluk (Kazan)

схема и пакты - неймспес, будем спорить ;) ?

Senya_LИ как справляется с версиями Posgres по сравнению с FB? Про сборку говорили, что только недавно стало возможным сборка вне монопольного режима и то вручную.

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

Senya_L
Не совсем понятно, что вы понимаете под словом "неконсистентный"? Если что-то имеете против против уровня изоляции READ COMMITED у версионника, то совершенно напрасно. Из прочтения мануала понял, что в Postgres'е два уровня, причем низший сответствует SNAPSHOT у FB, а второй to SNAPSHOT TABLE STABILITY. Маловато будить (С) Мультик :)

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

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

2кдв

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

Dimitry Sibiryakov
Т.е. такой, который не видит закоммиченных (COMMITED) записей на момент
чтения (READ). Ну... терминология оракула всегда была... странной.


такой read commited в oracle, mssql, mysql/innodb&falcon, postgres, т.е. в любом другом версионнике. зачем не конститентная каша блокировочнику - понятно, от бедности, repeatable read задыхается в блокировках с дедлоками, но нафига эта каша в верионнике ФБ я пока не понял, ладно кажется там (в ФБ) снепшот все таки по дефолту импользуется.

Dimitry Sibiryakov
ЕМНИП, у этого "нормального версионника" read commited позволяет читать
(READ) незакоммиченные (UNCOMMITED) изменения других транзакций.

у mssql2k5 есть read_commited_snapshot, речь о нем. грязное чтение на блокировочном read commited - даже при всех ляпов мсскл не верю, вы случайно не путаете с приколом когда можно прочитать данные строки из индекса в то время как на строку наложена эксклюзивная блокировка ?

Dimitry Sibiryakov
Тоже мне, Станиславский...

ну тады воспроизводимый пример кода в студию или мусье лишь ворочить языком горазд ?

2Dimitry Sibiryakov

жесть ...
даже и не знаю как на пальцах объяснить ... в процетированом куске речь идет о феноменах, это чуток другой природы явления нежели грязные (uncommitted) данные данные. менно эти феномены к стате говоря и вылазят в ФБ на read committed, но появление этих феноменов не означает, что возникнет способность прочесть грязные данные. нельзя в мсскл получить грязное чтение на read committed.

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

Senya_L
Я так и понял, чем нормальный, "рабочий" read comimted в Firebird вам не угоден? И вообще это похоже на религиозный бред.
а это лишь от того, что вы не поняли даже о чем собственно я толкую. в прочем как и со стабильностью курсора

Senya_L
Подходя к вопросу разумно: без такой "каши", чтобы увидеть изменения, сделаные в других транзакциях, надо делать запустить новую транзакцию (надеюсь, понятно выражаюсь). Нафига?
угу, предельно понятно .. понятно, что ни понятие RC ни версионика вы не осилили. да, и поверьте каша получаемая в одном запросе и "увидеть изменения, сделаные в других транзакциях" несколько разные явления ...

2kdv

формально да, тут ФБ совершенно не противоречит RC, но в реальной жизни чтоб жить с этой кашей в наборе нужно гораздо более квалифицированное проэктирование, очень окуратное кодирование и недюжуя изобретательность, чтоб не влипнуть. имхо нормальный snapshot/RC_snapshot настолько упрощает жизнь, что полезность такого "блокировочного RC" становится сильно меньшая.
а со стабильностью курсора - так, что в 2.5 что-то изменится ?

2Senya_L

неа, не понимаете. delete from всего лишь один из случаев огромного кол-ва вариантов неправильного поведения.

kdv
у FB может и рынка нет, но нишу он занимает приличную, и большинству из этих сотнен тысяч разработчиков (!) пофиг нестабильность курсора.
дык не удивительно, если у вас разработчики не все разобрались о чем речь, понятно что 99% пользователей даже не подозревают об этой проблеме.