мускулькапец?

Он же под MPL. А предводитель вашей секты RMS придал анафеме всё что не L/GPL. Так что это не тру.

А безопасность на уровне столбцов/строк есть?

Слава разработчикам! Потрудились на славу - обновлений просто дофига.

> А безопасность на уровне столбцов/строк есть?

А по-русски?

Хорошая новость.Неплохая имхо базка.

на уровне столбцов есть. а у кого есть безопасность на уровне строк?

А чем оно лучше PostgreSQL?

Больше БД хороших и разных.

Интересно, а когда наконец - ФС будут по умолчанию прямо над БД реализовывать?

> А чем оно лучше PostgreSQL?

Оно, говорят, легче + на неё, на сколько я понимаю, достаточно легко переводится всё, что было завязано на InterBase. То есть это счастливый шанс отвыкать постепенно для подсевших на продукты Borland.

Открой для себя Reiser4.

> Больше БД хороших и разных.

БД не нужны.

> Интересно, а когда наконец - ФС будут по умолчанию прямо над БД реализовывать?

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

"Если вы используете дополнительный слой для хранения данных, у вас просто плохая файловая система." (Г. Рейзер)

Наличием embedded-версии, например, которая не требует отдельной установки и может распространяться вместе с программой.

А вообще - просто разные базы, и у той, и у другой есть свои вкусности

"Рейзер должен сидеть в тюрьме" (с)

А по топику: хорошо! Пока Сан своими руками зарывает вечную недоделку MySQL, пусть плодятся и развиваются полноценные БД.

> БД не нужны.

4.2 Открой для себя теорию множеств.

> "Если вы используете дополнительный слой для хранения данных, у вас просто плохая файловая система." (Г. Рейзер)

Другими словами, нужно использовать ZFS. У ней нет LVM. :D

Как я понимаю, т.к. в 3.0 обещана многопоточность, то эта самая 3.0 выйдет уже не при нас

> Наличием embedded-версии, например, которая не требует отдельной установки и может распространяться вместе с программой.

спасибо, насмотрелись на кучу клиент-банковских программ на fb, которые помимо своих глюков, еще и конфликтуют между собой (а начальство требует чтоб всё было на 1 ноуте чтоб легко было унести, а самих клиент-банков уже десяток)

ЗЫ для встроенных систем есть sqlite -- простое, лёгкое, вылизанное и хоть 100 программ будут его использовать на 1 машине конфликтов не будет.

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

Врунишка :)

>Давно пора предать анафеме базы данных, так как это лишняя абстракция поверх файловой системы.

ФС - это абстракция которая тормозит под Ораклом. Даешь сырые партиции.

Без SMP он все равно не нужен

> Без SMP он все равно не нужен

Во-первых нужен

Во-вторых есть суперсервер

В-третьих SMP обещают в 2.5 (частично) и в 3.0 (полностью)

FB2.1

Одобрям :). Если разные файлы библиотек (а они должны быть разными, то есть каждая идти со своим клиентом) обращаются к разным файлам БД (а так и должно быть, так как embedded версия монопольно обращается к файлу), то проблем не должно быть в принципе :)

> Больше БД хороших и разных.

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

> MySQL будет выглядеть писец какой навороченой.

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

По поводу остального тоже не все так просто, но это отдельная тема. Говоря коротко - несмотря на известный список недостатков (а у кого их нет?) Firebird не так уж плох и ниша у него довольно обширная. Будем надеяться, что стараниями разработчиков скоро она станет еще шире. :)

> Интересно, а когда наконец - ФС будут по умолчанию прямо над БД реализовывать?

Если под БД понимается РСУБД, то пока не собираются ибо никому оно особо и не нужно.

А так ФС является БД, только специализированной :)

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

>то даже MySQL будет выглядеть писец какой навороченой.-Вот не надо тут.Если еще 5 версия пытается косить под нормальную СУБД то то что было ранее вообще никуда не лезет.

>так что оракл на фффсе ! -смешно))

>С мускулом есть проблема: InnoDB в его составе развиваться больше не будет, а новые движки пока не довели даже до его уровня, не говоря о том, чтоб превзойти. И скорее всего в ближайшем будущем это тоже не светит.

Санки хочет клинтов на свое железо, поэтому будет развивать innodb давая клиенту законченое решение, от железки до java+mysql. innodb это GPL, потому ничто его развитие не остановит. ну не пренадлежит часть кода Санкам, ну и что с того, на тот же MySQL EE edition покупка innodb нисколько не повлияло.

>Будем надеяться, что стараниями разработчиков скоро она станет еще шире. :)

3 разработчика погоды не сделают. со времен ИБ по сути ничего грандиозного не сделано, основные косяки не выпрямлены. SMP так и нет, оптимизатор как и был в плачевном состоянии, остается каша в уровнях изолированости (как они умудрились на версионнике при Read Commited неконсистентный набор получать), SQL не развивается, лог только в планах ... за это время тот же MySQL сделал прорыв, Postgres почти дотянулся до oracle8. темпы на фоне остальных (я не говорю о лидерах Oracle, Db2) слабоваты, ведь даже выход 3.0 координально не поменяет расстановку сил.

Эта базёнка не тянет. Все на Постгрес!

>> Интересно, а когда наконец - ФС будут по умолчанию прямо над БД реализовывать?

>Если под БД понимается РСУБД, то пока не собираются ибо никому оно особо и не нужно.

Да, имелось в виду именно современные реализации СУБД.

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

> Интересно, а когда наконец - ФС будут по умолчанию прямо над БД реализовывать?

Есть мааааленькое "но" - древовидные структуры, такие как ФС, очень херово ложаться на РСУБД. Впрочем, так же как и метаданные...

Советую попробовать реализвать proof of concept на FUSE и PostgreSQL, и потом рассказать о том с какими проблемами столкнулись...

> Советую попробовать реализвать proof of concept на FUSE и PostgreSQL, и потом рассказать о том с какими проблемами столкнулись...

Да это есть уже. Другое дело действительно близко не смотрел.

Реализация деревьев как типа данных над PostgreSQL тоже есть (если не путаю). Но проблему осознал. IMHO, всё-таки всё пока упирается в быстродействие и отсутствие СУБД в системе по умолчанию.

> Санки хочет клинтов на свое железо, поэтому будет развивать innodb давая клиенту законченое решение

Сейчас какого-то особого развития не видно - наоборот, усиленно вылизываются несколько новых претендентов на движки (тот де Falcon, например). А то, что ни одна корпорация, находясь в здравом уме, не станет развивать несколько схожих по функциональности решений - думаю, ясно и ежу. В этом смысле заморозка InnoDB - это еще не самая худшая из бед, гораздо хуже будет, если охмуренные Джимом сотрудники пересобачатся с саном и начнут независимую разработку. Станут ли сановцы поставлять со своим железом написанный "дядей со стороны" код - еще очень большой вопрос, а принятие стратегических решений теперь зависит исключительно от них.

> 3 разработчика погоды не сделают.

Конечно. Именно поэтому их у Firebird несколько больше. :)

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

>Интересно, а когда наконец - ФС будут по умолчанию прямо над БД реализовывать?

мусье знает толк в извращениях, чем фс над базой данных лучше фс над блочным устройством?

> фс над базой данных лучше фс над блочным устройством?

Современная ФС - это СУБД над блочным устройством :)

>А то, что ни одна корпорация, находясь в здравом уме, не станет развивать несколько схожих по функциональности решений - думаю, ясно и ежу.

а ежи корпорации не забыли оповестиь ? Sybase ASE & ASA, IBM AS/400 & pSeries, Oracle OEBS & Sibel, Sun Sparc & x86 - да любой ИТ гигант имеет десятки схожих технологий.

>Станут ли сановцы поставлять со своим железом написанный "дядей со стороны" код - еще очень большой вопрос

лапоть - подавляющее большинство их x86 серверов УЖЕ идут с чужим Linux кодом, в том числе и innodb.


>Сейчас какого-то особого развития не видно - наоборот, усиленно вылизываются несколько новых претендентов

не хитрый поиск и смотрим, что они выкатили на этой недели :)
http://www.innodb.com/innodb_plugin/features/

ежу ясно, что ничего из этого в ФБ даже не запланировано на это десятилетие ?

ЗЫ. а разработку Джима (Фалькон) можно смело сливать в унитаз. кончено по сравнению с архитектурой ФБ это офигительный шаг вперед (UNDO лог, вместо порнухи со сборкой мусора, буферный кеш, лог транзакций и т.п.), но этот горе проэктировщик запихнул UNDO в кеш и перемешал их, т.е. длинные транзакции там будут вымывать кеш и просаживать все остальное.

> а ежи корпорации не забыли оповестиь ? Sybase ASE & ASA, IBM AS/400 & pSeries, Oracle OEBS & Sibel, Sun Sparc & x86 - да любой ИТ гигант имеет десятки схожих технологий.

Перечислено, однако, в каждом случае почему-то по две. Для мускуля сейчас это как раз InnoDB + myISAM, в будущем - что_то_еще + myISAM. Нет, остальные движки, конечно, тоже останутся, в качестве рудиментов и "конфетки" для экспериментаторов, но ждать, что Sun будет делать ставку на их полноценное развитие - просто глупо.

> не хитрый поиск и смотрим, что они выкатили на этой недели :) > ежу ясно, что ничего из этого в ФБ даже не запланировано на это десятилетие ?

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

>Разумеется, учитывая, что большинство этих "суперфич" в нем есть практически с рождения.

суперфичи это из серии нарушения декларативности SQL или отсутствие кеша плана запросов, может лога или кривоватого для версионника READ COMMITED ? если ущербный MySQL просто прекратит свое развитие то ФБ лишь через лет 8 догонит его нынешнее состояние, но судя по передвинутым в 2004ом планам выпустить ФБ3 в 2006 году даже это сценарий под вопросом.

Отличный проект, правда, развивается неспешно.

>Он же под MPL. А предводитель вашей секты RMS придал анафеме всё что не L/GPL

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

>Так что это не тру.

а что ты там треш нам и так ясно исходя из твоего идиотского поста

>> А чем оно лучше PostgreSQL?

>Оно, говорят, легче + на неё, на сколько я понимаю

оно еще и как embeded может работать, вроде sqlite-а, только "пожирнее" емнип

В связи с кончиной MySQL FB теперь наше второе все после PG?

> спасибо, насмотрелись на кучу клиент-банковских программ на fb, которые помимо своих глюков, еще и конфликтуют между собой (а начальство требует чтоб всё было на 1 ноуте чтоб легко было унести, а самих клиент-банков уже десяток)

Кривым рукам девелопера никакая СУБД не помеха, увы.

> ЗЫ для встроенных систем есть sqlite -- простое, лёгкое

Embdended FB - это не решение для встроенных систем, факт.

>Другими словами, нужно использовать ZFS. У ней нет LVM. :D

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

яркие представители класса "профбздотролль-обыкновенный"

> нарушения декларативности SQL

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

> отсутствие кеша плана запросов

Кому он нахрен нужен? Извращенцам, плюющимся однотипными запросами через CGI-молотилку? Так им прямая дорога в дурку. Все адекватные люди давно используют prepared statement и не парятся с такой х..ней.

> может лога

Аналогично - на хрена? Все, что закоммичено - в базе FB остается железно, все, что не закоммичено - не останется и в логе. И фиг ли в нем толку в таком разрезе, кроме сомнительной радости от point-in-time recovery?

> кривоватого для версионника READ COMMITED

Скорее чьих-то кривоватых передних конечностей. У нормальных людей READ COMMITTED работает нормально, а дураку, как известно, даже если золотой член приделать - он и руки сотрет и орган поломает.

> если ущербный MySQL просто прекратит свое развитие то ФБ лишь через лет 8 догонит его нынешнее состояние

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

> "Рейзер должен сидеть в тюрьме" (с)

Чем так, кстати, дело закончилось? Посадили/нет? И можно ли ему будет, сидя на нарах, поддерживать reiserfs4?

http://blog.wired.com/27bstroke6/hans_reiser_trial/index.html

>Современная ФС - это СУБД над блочным устройством :)

я так понял предлагалось построить нечто такое: hard-drive -> fs -> субд -> fs

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

hard-drive -> субд -> fs API -> приложение

IMHO смыслов есть несколько:

а) естественное индексирование

б) естественная атомарность операций

в) легко расширяемые атрибуты

г) полнотекстовый поиск из коробки (с индексированием, естественно, и для файлов которые это позволяют)

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

е) естественный доступ по сети

ж) репликация

Список можно продолжать

отличная СУБД - 60-70 пользователей, 35 гигов база, 2 года - полет нормальный.

P.S. Оно просто работает.

>А у мускуля - косяки с неявным преобразованием типов

ну тогда примеры SQL которые приведут к отличным к примеру от оракла результатам в студию !

>Все адекватные люди давно используют prepared statement и не парятся с такой х..ней.

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

>кроме сомнительной радости от point-in-time recovery

кроме радости point-in-time которую имеют даже самые захудалые из субд (кроме жертвы аборта ФБ) лог - возможность продублировать изменения на тучу HDD, а вот дублировать всю базу - идиотизм. кроме этого к примеру ораклу лог дает стенбай и stream репликацию.

>У нормальных людей READ COMMITTED работает нормально

понятно что работает нормально, нормальные люди используют Postgres, Oracle, Mysql/inndob, MSSQL (c MVCC) и ниодна из этих версионников не вернет не консистентный набор на read commited, только ФБ.