аинтересно это как ? у них же нет гарантии атомарности даже в пределах запроса, т.е. результат зависит от порядка подзапросов в запросе ... это э получается что на один запрос можно получать разные ответы в зависимости от нагружености разных процов :)

Тихо и незаметно? ты только это разработчикам не говори!!, а вообщето SMP классик прекрасно поддерживает дай бо где то с 0.9 !

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

мускуля??? это в чем он конкурент????? где у него хотябы транзакции?, не надо путать божий дар с яишницей!, далее - пары энтузиастов? глубоко неуважаемый, вы в своем уме? для таких тупых и уперты гугля в помощь с ключевыми словами interbase/firebird. и вообще полезно перед высказываниями (типа умными) имень представление об обсужлаемемом предмете!

для тех, кто в танке...
1. в мускуле ЕСТЬ транзакции
2. interbase != firebird

Где, покажи, в мускуле транзакции? Только стабле плз.

interbase != firebird ясен пень firebird >= interbase

> interbase != firebird ясен пень firebird >= interbase
не путайте забаву любителей и полноценное комплексное решение с круглосуточной техподдержкой.

в mysql транзакции лет 5 и стабле с 3.x ветки:
http://dev.mysql.com/doc/mysql/ru/InnoDB_overview.html

после ниши mysql идет posgres дальше оракл, у меня mysql и oracle ... куда и главное для чего нужен firebird не понятно. я понимаю они бы сореновались бы с mysql, но нахера с таким кривым оптимизатром гонятся за posgres ??

> я понимаю они бы сореновались бы с mysql, но нахера с таким кривым оптимизатром гонятся за posgres ??

с мускулем им слабо соревноваться - он слишком быстрый.

Обьясните, он странички теперь быстрее будет открывать или где?

http://dev.mysql.com/doc/mysql/ru/InnoDB_overview.html Ты почитай повнимательнее про реализацию и как оно работает. Это затычка, а не транзакции. Так еще прочитай про хранимые процедуры и про вложенные запросы, а потом только говори о сравнении еще старой interbase vs mysql.

> Обьясните, он странички теперь быстрее будет открывать или где?

я лежал!!! :-)
ну ты и зажОг!!!

СУБД это система управления базами данных,
а браузер это FireFOX ;-)

Это затычка, а не транзакции. Так еще прочитай про хранимые процедуры и про вложенные запросы, а потом только говори о сравнении еще старой interbase vs mysql.
--------
оно так и должно быть, если я решаю серьозные задачи где мне нужны сложные запросы и сторед процедуры я возьму оракл. если что-то простенькое для веба - mysql.
а firebird - тормоз в сравнении с mysql на простеньких запрсах, ничего выдающегося на средненьких и полноый отстой на тяжелых (в сравнении хотябы с posgres). кривые транзакции которые немогут обспечить ни одного из извесных в sql92 уровней изоляции (даже dirty read :) ), так в какой области его юзать ? он хорош лишь в том что есть хоть какой-то конкурент у mysql.

В 4.1.8 транзакции есть, настраивается через mysql admin :)

Это где такое написано, что Постгре быстрее Фаерберда? Что-то бездоказательно утверждать - ляпнул - и хоть трава не расти!

Это где такое написано, что Постгре быстрее Фаерберда? Что-то бездоказательно утверждать - ляпнул - и хоть трава не расти!
----

читаем внимательно новость и осознаем что firebird скалится до 2.0 на SMP не умел, у postgres не как оракл но скалится.

Еще раз. Почему нигилистические высказывания чаще всего делают те, кто сам этим не занимается? Риторический вопрос :).

1. Файерберд не умеет СМП в архитектуре суперсервер. В архитектуре классик он это умеет.

2. Давайте говорить о полезности - производительности приложения в контексте задачи. Вы (лично Вы) решаете задачи масштаба предприятия с одновременными сотнями транзакций? Люди, которые действительно решают такие задачи, обычно более точны в своих высказываниях (особенно буржуи). И даже многим из них Файрберд подходит и решает их задачи.

Если Ваши задачи ограничены базой в каких-то единицы или десятки гигабайт и загрузкой 24*7, то Фаерберд такие задачи решает.

poskipano...

> так в какой области его юзать ?

uvazhaemyi anan-imus zabyl pro srednie proekty pod win32
a lya off-line komunalnye platezhy, sklady i t.d. i t.p.
budem mysql stavit' ili oracle? ;)
ili budem potom dbf-ki ruchkami pravit' i dannye po swapu iskat'?
:)

да, лично я решаю задачи на сотни транзакций, эти задачи у меня решает oracle, часть задач решает oracle collboration suite т.е. oracle portal и oracle workflow. там оракл полезен.
еще есть некая CMS на php и пара простеньких задач в 20-30 экранов где не нужны транзакции. их у меня решает mysql, т.к. время реакции oracle portal раз в 3-5 больше чем php+mysql.

вернемся posgres как я слышал там есть схема, есть понятия файла и распределение i/o нагрузки по файлам + имеет не супер но хоть какой-то оптимизатор и sql92 уровни изолированости транзакций. то что firebird рещает какие-то сложные задачи то конечо плюс, но например кабол решает тоже mission critical задачи (большинство банковских транзакций в США эо кобол), но врядле это говорит об го архитектурной крутизне ...

Верно,.. и довольно не плохо решает...

многие знакомые разработчики, использующие Delphi предпочитают при больших нагрузках использовать Oracle, при средних и малых - Interbase/Firebird... почему не MySQL понятно, но вот почему не PostgreSQL? многие отвечают так, что, мол,.. в Delphi существует множество библиотек и возможностей для работы с Interbase(Firebird).. потому как, и то и другое имеет Borland-овские корни.. а под PostgreSQL надо самим реализовывать эти возможности или искать сторонние... вообщем, в данной комбинации больше доверяют Interbase/Firebird...

>многие знакомые разработчики, использующие Delphi предпочитают

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

c мускулом сабж imo никак не может конкурировать - разные профили (типа грузовик и феррари формула1), а вот с постгрессом очень даже

> uvazhaemyi anan-imus zabyl pro srednie proekty pod win32 > a lya off-line komunalnye platezhy, sklady i t.d. i t.p. > budem mysql stavit' ili oracle? ;) > ili budem potom dbf-ki ruchkami pravit' i dannye po swapu iskat'?

Мускула тут более чем достаточно. Чё за склад? База по-любому меньше гигабайта. Мускул на таких базах всех порвёт, если конечно у разработчика нет повёрнутости на хранимых процедурах и триггерах.

> c мускулом сабж imo никак не может конкурировать - разные профили (типа грузовик и феррари формула1), а вот с постгрессом очень даже

Сабж - это грузовик типа газели, из категории "дешево и сердито". А если нормальный грузовик нужен - это Оракл.

P.S. А феррари - это мускул :)

> Сабж - это грузовик типа газели, из категории "дешево и сердито". А если нормальный грузовик нужен - это Оракл. P.S. А феррари - это мускул :)

ну да, пусть в боллиде удобств мало, пассажиров тоже, грузоподьемность и безопасность оставляет желать лучшего, но главное что шампанское после гонки будет пить именно пилот этой формулы :)

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

Он ни в коей мере не конкурент мюскля. Мюскль - это sql-сервер для динамических веб-страниц. Смысл его применений - задачи, когда число выборок на порядки больше числа модификаций базы. А Interbase/Firebird - это полноценная база данных для бизнес-приложений. А что касается уровня DirtyRead - не могу представить в страшном сне, зачем нужно видеть _неподтвержденные_ данные чужой транзакции? Мало ли что в ней может быть...

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

>так в какой области его юзать ?

У него есть определенно неплохое применение для небольших приложений а ля каталоги на CD или приложений где нужна локальная БД. Есть вариант встраивания в свое приложение Firebirdа как небольшой dllки и сама БД у него в виде одного файла, что очень удобно для такого класса задачь.

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

Из недостатков (то что было в 1.5 может в 2.0 уже это поправили) мне бросилось в глаза то что:

-он не может создать новых пользователей при помощи SQL команды (пришлось писать сторедпроц),

-с кириллицей у него есть вопросы (для правильных сортировок нужно специальные DDL делать нестандартные)

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

От PostgreSQL он по возможностям конечно очень отстал, особенно от ПГ 8.0, но это восновном серьезные фичи, которые далеко не всегда нужны. По скорости я заметил субъективно тормознутость по сравнению с ПГ. Но я юзал его через Jaybird JDBC так что может сам FB и не виноват был.

С MySQL не сравнивал и с прямым доступом к текстовым файлам тоже не сравнивал, наверно они выгребают данные быстрее всех.

Re:

> где у него хотябы транзакции?

Хотя бы транзакции у него с 4.0. Правда, в 4.0 они еще более убитые, чем в FB-1.x (в полторашке). А вот то, что у FB-1.5, как меня уверяют наши девелоперы нет штатных механизмов онлайн бэкапа - это уже жопа, извините.

FB к сожалению не подходит для использования и в качестве встраиваемой базы данных. Весит 1.5 мегабайта и требует для работы полноценный TCP/IP стек. В таком варианте гораздо проще выбрать SQLite, который хоть и гораздо проще по возможностям, но весит 300К в виде 1 длл-ки и не требует сети совсем. Бинды под Дельфи есть для того и другого. Шароварщики, которые занимаются именно такими конфигурациями, меня поймут.

Re:

На тебе "Штатный механизм бэкапа"

gbak -T -B -u user -p paswwd "file1.fdb" "file2.fbk"

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

транзакции в мускуле обеспечиваются не костылями, а для таблиц InnoDB и BDB.

По умолчанию используются MyISAM (разработанные почти с нуля, т.е. полностью переписанные ISAM и поддержку которых из 5-й версии выкинут), как раз они то и обеспечивают скорость на которой мускуль всех и кидает

InnoDB разрабатывалась как максимально быстрая транзакционная база (здесь и таблицы по другому храняться). Из доки:

"Таблицы InnoDB в MySQL снабжены обработчиком таблиц, обеспечивающим безопасные транзакции (уровня ACID) с возможностями фиксации транзакции, отката и восстановления после сбоя. Для таблиц InnoDB осуществляется блокировка на уровне строки, а также используется метод чтения без блокировок в команде SELECT (наподобие применяющегося в Oracle). ... InnoDB предназначается для получения максимальной производительности при обработке больших объемов данных. По эффективности использования процессора этот тип намного превосходит другие модели реляционных баз данных с памятью на дисках"

единственное общее у всех типов таблиц - это парсер, который разбирает SQL

Re:

Ага. "И так - восемнадцать раз". Потрудитесь перечитать, пожалуйста, то, что я написал.

>По скорости я заметил субъективно тормознутость по сравнению с ПГ.

ничего удивительного - пг использует кост бэйзд оптимизатор, фб - рул бэйзд. фб на сложных запросах проседает конкретно - например довольно часто встречаются ситуации когда даже простой запрос ( например 3 джойна и груп бай с хевином) работант бесконечно долго, загружая цпу и ио на 0%. Бакап ненадежен - используя гбак можно заполучить ИНКОНСИСТНЫЙ архив - т.е. архив, из которого невозможно восстановиться!!!. Невозможно на ихнем ПЛ/СЭКУЭЛ сделать функцию, более того - сделать функцию, которая в процессе работы ходит в базу - невозможно в приципе! и т.д. и т.п. ...

Было бы приколно посмотреть на камикадзе, который имея в схеме хотябы 300 - 400 таблиц, 10 - 20Г базуху и ~100 конкур.сессий взгромоздит ее на фб - а ведь это даже не средняя система...

>1. Файерберд не умеет СМП в архитектуре суперсервер. В архитектуре классик он это умеет.

И что? Нужто запросы, и ио распаралеливает? Насколько я знаю все, что он умеет это форк. У него даже нет общего буферного кэша! Хе-хе, тогда bash тоже умеет СМП.

>сли Ваши задачи ограничены базой в каких-то единицы или десятки гигабайт и загрузкой 24*7, то Фаерберд такие задачи решает

без надежного архивирования? нет не решает.

>довольно часто встречаются ситуации когда даже простой запрос ( например 3 джойна и груп бай с хевином) работант бесконечно долго, загружая цпу и ио на 0%.

точно на 0%? что-то я с таким не встречался, вот на 90-99% это бывало...

>Бакап ненадежен - используя гбак можно заполучить ИНКОНСИСТНЫЙ архив - т.е. архив, из которого невозможно восстановиться!!!.

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

>Невозможно на ихнем ПЛ/СЭКУЭЛ сделать функцию, более того - сделать функцию, которая в процессе работы ходит в базу - невозможно в приципе!

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

>точно на 0%? что-то я с таким не встречался, вот на 90-99% это бывало...

0% - (ноль процентов) в этом то и фишка! Или 'where blabla = 1' приводит к угребищному плану, и 'where blabla in ( 1 )' приводит к к угребищному плану, а 'where blabla in ( 1, 1 )' приводит к нормальному плану. Короче , когда таблиц в запросе >3, и хотябы в одной из них ~6-8 M записей - такие сюрпризы не исключение, а почти правило. Трахались до недавнего (к стати с фб 1.5) времени - знаем.

>неполадки и чрезвычайные ситуации возможны в любой системе... а

Согласен на все 100% НО - АРХИВИРОВАНИЕ оно для того, чтобы после этих неполадок ВЫЖИВАТЬ, а если архиву нельзя доверять ....

>ато у них есть процедуры, обеспечивающие функциональность, похожую на ту, что обеспечивают функции в других диалектах...

так ить функцию можно использовать в любом количестве запросов - а процедура в фб - это по сути запрос - причем замороженный. Разница велика есть...

Ой, ви мене улыбаете. А как оно 2 года до этого работало? На SMP. Причем, используя оба проца.

ананимусу с задачей на сотни транзакций... в день. Оракл - из пушки по воробьям. Очень-очень дорогой пушки.

"Мускул на базах мешьше гига всех првет" mous (*) (10.01.2005 20:21:32) а потом придут и порвут а*с разработчику, т.к. если задача серьезная, то линейных запросов с одиночными транзакциями на вставку не хватит - нужны и SP, и транзакции и сложные запросы...

>> с кириллицей у него есть вопросы (для правильных сортировок нужно специальные DDL делать нестандартные) ни разу не видел проблем с кириллицей. У постгре - постянно видел

Для встраиваемых задач с одной dll - есть Yaffil Personal. В новых версиях даже dll нет.

>> anonymous (*) (11.01.2005 13:29:38) он на это и не расчитан

Простые задачи с несколькими десятками таблиц по нескольку лимонов записей и размером базы в пару гиг при 2-3 десятках одновременных соединений (с простыми и средними запросами и, периодически, парой тяжелых) решает "на ура". Применение Оракла в такой системе экономически нецелесообразно, того, кто заикнется о майскул для такой задачи я к компу не подпущу.

http://www.ibase.ru/devinfo/norestore.htm

>Согласен на все 100% НО - АРХИВИРОВАНИЕ оно для того, чтобы после этих неполадок ВЫЖИВАТЬ, а если архиву нельзя доверять ....

Пока что бог миловал, выживали.. (тьфу-тьфу-тьфу...) ;-)

>так ить функцию можно использовать в любом количестве запросов - а процедура в фб - это по сути запрос - причем замороженный. Разница велика есть...

да, это верно.. есть разница... но тут на помощь могут прийти расширенные функции, пишешь библиотеку, на том же C/C++ или Delphi, обьявляешь функции и используешь так называемый UDF.... а вообще-то, всё это, конечно, неудобно... если сравнивать с тем же PL/pgSQL...

>Ты почитай повнимательнее про реализацию и как оно работает. Это затычка, а не транзакции.

ну-ка, ну-ка, поподробнее тут... Какие у вас претензии к транзакциям innodb?

Re:

> На тебе "Штатный механизм бэкапа"

> bak -T -B -u user -p paswwd "file1.fdb" "file2.fbk"

После этих слов мне почему-то вспомнилось, что для администраторов Oracle в программе обучения DBA есть целый курс по бэкапу.

Re:

а кто нибудь видел/слышал о применении mysql cluster ? он shared nothing но как я понял на бумаге там получается еще и отказоустоичивость какая-то.

ЗЫ. ворочить милиоными табличками на оракле вполне адекватно,если $5K дорого то все равно приятней на нормальной субд типа postgres или sybase (ASE под линух бесплатен но с ограничениями).

> ни разу не видел проблем с кириллицей. У постгре - постянно видел

Я имею ввиду необходимость таких вот конструкций

CREATE TABLE USERS1 ( FNAME VARCHAR (30) COLLATE PXW_CYRL, LNAME VARCHAR (30) COLLATE PXW_CYRL );

Точно уже не помню, но без COLLATE PXW_CYRL кажется не работают такие вещи как like.

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

И еще хочу сказать всем, что это просто счастье, что есть столько разных халявных СУБД. Они друг с другом конкурируют и нам есть из чего выбрать. Мне лично очень нравится и Постгрес и ФБ.

А вот любителям Оракла я не завидую, потому что в этом супер пупер ДБ за фигову тучу денег невозможно сделать что-то типа LIMIT,OFFSET или TOP, только через жопу. А ведь такие полезные операторы.

>А вот любителям Оракла я не завидую, потому что в этом супер пупер ДБ за фигову тучу денег невозможно сделать что-то типа LIMIT,OFFSET или TOP, только через жопу. А ведь такие полезные операторы.

вам объяснить объяснить почему у оракла нет такой "полезной" фичи, или чуть подумаем и сами догадаемся ? ;)

> где у него хотябы транзакции?

> с яишницей

> обсужлаемемом

1. Выучи великий и могучий русский языка.

2. Выучи MySQL. В JPL, наверное, одни дураки, не то что форумные умники-бездельники.

3. Тебя видно сильно "обижали" в ДеЦТве (с), раз ты пытаешься отыграться, оскорбляя окружающих.

Я, конечно, понимаю, что типа ФБ - это сакс и все такое, но вот почему он настолько популярен? Что, все остальные, которые не разделяют вашего мнения - дураки? Чтобы не быть голословным насчет популярности - http://sql.ru/poll/. Там второй сверху - опрос "Какую СУБД вы используете для работы". Конечно, там ИБ, ФБ и Яффил идут в одном пункте, и, конечно, все только ИБ и используют; да и весь sql.ru настолько тупой, что даже не обратил внимание, что это разные СУБД... Или все же причина в другом?