Русская документация по языку SQL СУБД Firebird 2.5

[voicer]

Я думал, эта база уже умерла…

[zBit]

Тоже так думал. Мы использовали как-то её на одном проекте, а потом посмотрели, что обновлений не было уже несколько лет, подумали, что проект умер, поддерживать его никто не будет и решили перейти на динамично развивающийся в тот момент PostgreSQL, пока не стало слишком поздно :)
Для FB был клёвый менеджер IBExpert, очень мощный инструмент по тем временам. Он мне нравился, хоть и был староват. Причём была ещё новая версия, но мы, почему-то использовали старую версию (кажется потому, что она была «бесплатной»).

[dndred]

IBExpert и сейчас есть. Даже развивается.

[Greendq]

И даже бесплатен для exUSSR :)

[zBit]

Забыл добавить, что уже давно за FB не слежу, года так с 2011-го, т.к. думал, что он уже умер :)
Но это, несомненно, круто, что IBExpert до сих пор развивается!

[Suvitruf]

Я вот не в курсе, там какой-то особенный SQL, сильно отличающийся от оного в MySQL, Oracle и т.п.? Или же документация именно по самой СУБД?

[zBit]

Синтаксис MySQL от Oracle отличается местами, так же как и синтаксис PG или FB. У всех есть свои особенности.
Плотно работал с MySQL, Firebird и PostgreSQL. Например, первое что сильно бросается в глаза — отличаются лимиты и отступы, их место.

MySQL: SELECT `column` FROM `table` LIMIT 20, 10
PostgreSQL: SELECT "column" FROM "table" LIMIT 10 OFFSET 20
Firebird: SELECT FIRST 10 SKIP 20 'column' FROM 'table'

В MySQL нет WITH (Common Table Expressions), а в PG, MS SQL, Oracle и Firebird есть. Это очень мощный инструмент оптимизации запросов.

И это только вершина айсберга :)

Ещё отличаются: символы экранирования, конкатенация строк (в PG это просто ||), набор типов данных, способы написания процедур (в PG доступен очень похожий на оракловский plsql — pgplsql). Есть ещё много принципиальных отличий. Если поработать с этими РСУБД плотнее, то поймёшь на сколько сильно они отличаются.

Но главные отличия СУБД — это не синтаксис, а принцип работы с данными.

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

[AlexeyKovyazin]

Если открыть документацию Firebird (из статьи выше), то на стр. 140 узнаем, что лимиты выдачи по стандарту реализуются ROWS, а разнообразные FIRST, SKIP, LIMIT и прочее — это самодеятельность разработчиков разных СУБД.
Ну и далее в том же духе. Если хотите узнать, чем один диалект SQL отличается от другого, лучше самостоятельно почитать документацию, а не полагаться на слова бывалых.

[zBit]

лимиты выдачи по стандарту реализуются ROWS, а разнообразные FIRST, SKIP, LIMIT

Совершено верно! Я писал как раз про разницу между диалектами упомянутых РСУБД :)

[kirillzorin]

Так ведь ROWS — это тоже самодеятельность разработчиков Firebird.

Вы говорите:

то на стр. 140 узнаем, что лимиты выдачи по стандарту реализуются ROWS

Но в вашей документации явно не сказано, что ROWS из ANSI-стандарта (да и нет их там в стандарте в таком виде):

Внимание! FIRST и SKIP используются только в Firebird, они не
включены в стандарт SQL. Рекомендуется использовать ROWS везде, где
это возможно.

[sim_84]

ROWS тоже не из стандарта. По стандарту сделано только в 3.0

[OFFSET <simple_value_expr> {ROW | ROWS}]
[FETCH {FIRST | NEXT} [<simple_value_expr>] {ROW | ROWS} ONLY]

[Infanty]

Спасибо. Ещё бы подробнее бы рассказали про HL на Firebird. Покорила база своей надёжностью, а в купе с Hadoop + ZeroMQ (кластер управляется через очереди) на нескольких серверах получается неплохо выжимать и по производительности.

[AlexeyKovyazin]

А что у Вас за решение на Firebird+Hadoop? Ссылочку можно?

[Infanty]

Внутренний продукт :), собираем данные финансовой статистики на основе этого генерируем прогнозы. Краулер собирает данные и отправляет их в ZeroMQ, который раскидывае их на несколько серверов в кольце для дубликации данных (на случай если сервер умрёт — останется копия на другом сервере, на подобии как apache cassandra но с возможностью цеплять Hadoop отдельно к каждому серверу). Отдельно Hadoop — генерирует прогнозы обрабатывая данные из Firebird, при этом отдельно словари храним в Redis при расчётах. В принципе в такой схеме важно уже было удобство работы с базой данных из языка программирования на котором писал система (у нас freepascal + php), а производительность упиралась в производительность i/o, а не базы данных (Firebird или MySQL, PostgreSQL).

[AlexeyKovyazin]

Круто :) Не хотите сделать case study для сайта FirebirdSQL.org?

[Infanty]

Пока нет NDA :)

[Infanty]

Нашёл исходную презентацию на который ориентировались когда делали своё решение — www.docstoc.com/docs/149794081/Firebird_-MapReduce-Framework-for-Shared-memory-Machines и код к этой презентации — code.google.com/p/firebird-mapreduce/. Весь остальной обвес из ZeroMQ, логики дубликации на подобии как в apache cassandra и т.п. несложно добавить имея общий вектор развития который хорошо описан в презентации.

Так же архитектору базы данных и админу желательно иметь под рукой статьи по оптимизации на подобии: www.josh-hartmann.com/firebird-performance-tweaking/ и www.firebirdsql.org/file/community/conference-2014/pdf/16_tpcc_presentation.pdf

[Homas]

Ровно 10 лет назад я вытаскивал из файла БД Firebird 1.x (Interbase 6.x) удалённые данные :) Даже статью написал по этому поводу (всё ещё доступна на сайтах популярных в то время). Не думал, что ещё услышу что-то о Firebird.
Интересно внутренняя структура хранения данных м/у 1.x и текущей 2.5 сильно поменялась?