LINUX.ORG.RU

Firebird 2.1

 ,


0

0

Вышел релиз 2.1 реляционной базы данных Firebird.

Релиз включает в себя множество изменений, в т.ч.:

  • совместимые со стандартом SQL глобальные временные таблицы,
  • Common Table Expressions,
  • UPDATE OR INSERT фунциональность для MERGE,
  • добавлена объединяющая функция LIST(),
  • множество новых встроенных функций,
  • COLLATE в PSQL и команда СREATE COLLATION,
  • мониторинг базы через специальные виртуальные таблицы,
  • порт на Windows 2003 64-bit (AMD64 и Intel EM64T) Classic, Superserver и Embedded модели; PowerPC, 32-bit и 64-bit Intel Classic и MacOSX,
  • улучшен сетевой протокол,
  • и многое другое...
Скачать

>>> Подробности

Ответ на: комментарий от anonymous

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Korwin ★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от Korwin

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Korwin ★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.