Firebird 2.1

> MSSQL (c MVCC) и ниодна из этих версионников

А разве MSSQL - это версионник? Вроде же по жизни блокировочник.

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

можете пойти это рассказать M$, а то они тужатся winfs изобретают зачем-то

>А разве MSSQL - это версионник? Вроде же по жизни блокировочник.

в 2005ом добавили MVCC: IL snapshot и снэпшотный read commited

ЗЫ. oracle files уже лет десять, это оно и есть субд с интерфейсом файловой системы, если субд положить на сырые партиции, будет фс поверх субд. одна из фич в том что можно oracle workflow на эту байду одевать.

на уровне строк можно через вьюшки сделать

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

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

Вот, например: http://www.bitbybit.dk/carsten/blog/?p=122

Оракл, к слову, тоже не идеал - до сих пор трактует NULLы не по стандарту. И ничего - вокруг почему-то не собираются толпы дебилов, вопящих "оракля - жертва аборта".

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

Да уж, вот чего-чего, а CPU на современных машинах всегда не хватает. И причем именно на разбор запросов - все остальные операции летают полюбому, а как дело доходит до того, чтобы что-то распарсить - так все, на полчаса загрузка упирается в 100% . :) :) :) :) :) :) :) :) :)

> возможность продублировать изменения на тучу HDD

Накуй оно кому надо, если банальный RAID сделает ровно то же самое и с куда большей эффективностью? А, понятно - попонтоваться немеряной крутостью своих админских навыков. Ну ясно, тут FB не помощник - он как правило просто работает, без всяких распальцованных суперадминов.

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

>Оракл, к слову, тоже не идеал - до сих пор трактует NULLы не по стандарту. И ничего - вокруг почему-то не собираются толпы дебилов, вопящих "оракля - жертва аборта".

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

>И причем именно на разбор запросов - все остальные операции летают полюбому, а как дело доходит до того, чтобы что-то распарсить - так все, на полчаса загрузка упирается в 100% .

ну вообще согласен, жертва аборта имеет настолько продвинутый оптимизатор и настолько разнообразные методы доступа, что действительно потратить CPU на эту операцию у ФБ не выйдет :)
в оракле же на тяжелых OLTP на парсинг при кривом приложении не использующим бинд может уйти до +100% лишнего времени.

>Накуй оно кому надо, если банальный RAID сделает ровно то же самое и с куда большей эффективностью?

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

>и пару сотен гб лога задачи разных масштабов.

имелось в виду пару сотетен МБ ....

> а у кого есть безопасность на уровне строк?
IBM DB2

>RAID спасет всего в паре случаев из сотен вероятных проблем

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

Если нужна инфа по FB есть замечательная книга: Firebird - руководство разработчика баз данных (Хелен Борри)
Можете купить или скачать в формате djvu, после прочтения отпадут многие вопросы

> Оракл, к слову, тоже не идеал - до сих пор трактует NULLы не по стандарту. И ничего - вокруг почему-то не собираются толпы дебилов

Потому что "исправление" этого поведения приведет к автоматической несовместимости всего, что уже под Oracle написано.

> Да уж, вот чего-чего, а CPU на современных машинах всегда не хватает. И причем именно на разбор запросов
Вы будете смеяться, но таки да. Если рассматривать системы в которых добавление данных много чаще выборок.

> Накуй оно кому надо, если банальный RAID сделает ровно то же самое и с куда большей эффективностью?
RAID - кажущаяся панацея. На него может полагатья только "распальцованный суперадмин".

>В FB есть теневые копии баз данных, странно что вы будучим таким ярым критиком этого не знаете.

гы-гы, ну а теперь с нетерпением ждем рассказа чем это круче тупого RAID0 ?

>Если нужна инфа по FB есть замечательная книга: Firebird - руководство разработчика баз данных (Хелен Борри)

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

> понятно, что не собирутся, даже полному идиоту ясно, что стандарт это не последняя инстанция ... с MySQL - криво, согласен, но...

Ну ясно - "что дозволено Юпитеру...". Слив по этому пункту засчитан.

> ну вообще согласен

Ну и слава богу.

> в оракле же на тяжелых OLTP на парсинг при кривом приложении не использующим бинд может уйти до +100% лишнего времени.

Это проблемы Оракла. Впрочем, подозреваю, что и тут найдется куча причин, по которым "оно должно быть именно так и никак иначе". Юпитер же...

> RAID спасет всего в паре случаев из сотен вероятных проблем.

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

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

В кривых руках - да, конечно.

> Это проблемы Оракла.
Считаете, что постоянный парсинг и постороение алгоритма выборки _одинаковых_ запросов прибавит скорости по сравнению с разовым парсингом и анализом?
К слову: PrepareStatement здесь ни при чем.

> Че-та я не наблюдаю тут перечня проблем, не решаемых рэйдом и решаемых логом.
Есть центральная БД и есть ее "клоны". Центральную постоянно дергают на изменение. клоны, в основном работают на чтение.
Объемы в районе 500Gb активно используемых данных.
Клоны, в основном, размещены вне локальной сети центральной БД.
Как в этом случае поможет RAID и как поможет лог?

> Потому что "исправление" этого поведения приведет к автоматической несовместимости всего, что уже под Oracle написано.

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

> Вы будете смеяться, но таки да. Если рассматривать системы в которых добавление данных много чаще выборок.

Вы тоже будете смеяться, но препарить запрос отдельно для каждой вставки - не есть единственно возможный способ работы. Ни prepared statement, ни пакетный режим никто еще не отменял.

> RAID - кажущаяся панацея.

Что конкретно в нем не устраивает?

>Это проблемы Оракла. Впрочем, подозреваю, что и тут найдется куча причин, по которым "оно должно быть именно так и никак иначе". Юпитер же...

Это "проблема" любого cost based оптимизатора, кроме ФБ я больше не знаю живую клиент-серверную субд без cost based оптимизатора. именно поэтому у любой серверной субд есть кэш планов. даже в mysql.

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

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

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

Считаю, что в FB описанных для оракла проблем не наблюдается, а стало быть и решать нечего. Построение плана запроса тут - очень дешевая в смысле ресурсов CPU операция.

> К слову: PrepareStatement здесь ни при чем.

Ну да, канешна! (с)

> Клоны, в основном, размещены вне локальной сети центральной БД. > Как в этом случае поможет RAID и как поможет лог?

Разумеется никак. Причем ни тот, ни другой.

> Это "проблема" любого cost based оптимизатора, кроме ФБ я больше не знаю живую клиент-серверную субд без cost based оптимизатора.

Теперь внимание, вопрос: нахрена FB решать эту проблему, если она перед ним (по крайней мере пока) даже не стоит?

> любая ошибка пользователя с продвинутыми правами,

Point-in-time recovery обсуждался отдельным пунктом, не надо тут про суперпользователей.

> глюки RAID контроллера, катастрофа в серверной

Логи от этого застрахованы в принципе? Если нет - об чем вообще речь?

>Теперь внимание, вопрос: нахрена FB решать эту проблему, если она перед ним (по крайней мере пока) даже не стоит?

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

>Логи от этого застрахованы в принципе? Если нет - об чем вообще речь?

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

> в том то и дело, что такие базовые вещи как адекватный cost based оптимизатор, лог, cusor stability, документация перед ФБ даже не стоит ...

Очень смешно. Смотри не уписайся.

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

А удаленная машина, разумеется, не падает в принципе.

> Очень смешно. Смотри не уписайся.
> А удаленная машина, разумеется, не падает в принципе.

пипец. дальше не имеет смысла.

> дальше не имеет смысла.

Засчитано

>биллетристика на околоФбшные темы конечно хорошо, но субд без >документации это просто нонсенс.

Не читал, но осуждаю?

По FB полно ресурсов и статей, в отличии от многих других
открытых продуктов (того же GTK).
Есть и книги. И чтение поясниловки к релизам, в открытых продуктах тоже никто не отменял.

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

По поводу теневых копий БД. Это то самое средство, которое позволяет обойтись без RAID или лога транзакций. Это моментальный снимок данных основной БД.

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

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

Вы это, думайте что говорите. Атомарность требует дополнительных циклов записей то есть понижает скорость записи. Юзеры, пишущие видео или чего-там с сенсоров не пойдут на уменьшение скорости записи никогда и низачто, точка. Те, кому все эти undo/redo-логи будут гробить ресурс флешек, тоже не обрадуются.

Как ваша БД будет тянуть сьемные накопители? Это извините не PostgreSQL, а MySQL скорее получится - это там можно кусок БД в произвольный момент изъять а потом обратно вставить.

И вообще, сейчас есть файлы, которые можно хранить-получать-передавать. А в вашей БД что будет единицей хранения? типы данных? Вы, похоже, WinFS-ию где-то подцепили, поаккуратнее надо :-)

> СУБД (лучше PostgreSQL) сейчас можно ставить вообще по умолчанию практически на любую систему.

Например, в телефон ? и на vfat-флешку?

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

файловую систему с полнотекстовым поиском предъявите пожалуйста