Comments 19
Я думал, эта база уже умерла…
Тоже так думал. Мы использовали как-то её на одном проекте, а потом посмотрели, что обновлений не было уже несколько лет, подумали, что проект умер, поддерживать его никто не будет и решили перейти на динамично развивающийся в тот момент PostgreSQL, пока не стало слишком поздно :)
Для FB был клёвый менеджер IBExpert, очень мощный инструмент по тем временам. Он мне нравился, хоть и был староват. Причём была ещё новая версия, но мы, почему-то использовали старую версию (кажется потому, что она была «бесплатной»).
Для FB был клёвый менеджер IBExpert, очень мощный инструмент по тем временам. Он мне нравился, хоть и был староват. Причём была ещё новая версия, но мы, почему-то использовали старую версию (кажется потому, что она была «бесплатной»).
UFO just landed and posted this here
Я вот не в курсе, там какой-то особенный SQL, сильно отличающийся от оного в MySQL, Oracle и т.п.? Или же документация именно по самой СУБД?
Синтаксис MySQL от Oracle отличается местами, так же как и синтаксис PG или FB. У всех есть свои особенности.
Плотно работал с MySQL, Firebird и PostgreSQL. Например, первое что сильно бросается в глаза — отличаются лимиты и отступы, их место.
В MySQL нет WITH (Common Table Expressions), а в PG, MS SQL, Oracle и Firebird есть. Это очень мощный инструмент оптимизации запросов.
И это только вершина айсберга :)
Ещё отличаются: символы экранирования, конкатенация строк (в PG это просто ||), набор типов данных, способы написания процедур (в PG доступен очень похожий на оракловский plsql — pgplsql). Есть ещё много принципиальных отличий. Если поработать с этими РСУБД плотнее, то поймёшь на сколько сильно они отличаются.
Но главные отличия СУБД — это не синтаксис, а принцип работы с данными.
Вообще, поработав с большим количество СУБД, мне больше всех понравился в использовании PostgreSQL, это и инструменты для разработки и репликации, большой набор типов данных, расширения и многое другое.
Плотно работал с 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, это и инструменты для разработки и репликации, большой набор типов данных, расширения и многое другое.
Если открыть документацию Firebird (из статьи выше), то на стр. 140 узнаем, что лимиты выдачи по стандарту реализуются ROWS, а разнообразные FIRST, SKIP, LIMIT и прочее — это самодеятельность разработчиков разных СУБД.
Ну и далее в том же духе. Если хотите узнать, чем один диалект SQL отличается от другого, лучше самостоятельно почитать документацию, а не полагаться на слова бывалых.
Ну и далее в том же духе. Если хотите узнать, чем один диалект SQL отличается от другого, лучше самостоятельно почитать документацию, а не полагаться на слова бывалых.
лимиты выдачи по стандарту реализуются ROWS, а разнообразные FIRST, SKIP, LIMITСовершено верно! Я писал как раз про разницу между диалектами упомянутых РСУБД :)
Так ведь ROWS — это тоже самодеятельность разработчиков Firebird.
Вы говорите:
Но в вашей документации явно не сказано, что ROWS из ANSI-стандарта (да и нет их там в стандарте в таком виде):
Вы говорите:
то на стр. 140 узнаем, что лимиты выдачи по стандарту реализуются ROWS
Но в вашей документации явно не сказано, что ROWS из ANSI-стандарта (да и нет их там в стандарте в таком виде):
Внимание! FIRST и SKIP используются только в Firebird, они не
включены в стандарт SQL. Рекомендуется использовать ROWS везде, где
это возможно.
Спасибо. Ещё бы подробнее бы рассказали про HL на Firebird. Покорила база своей надёжностью, а в купе с Hadoop + ZeroMQ (кластер управляется через очереди) на нескольких серверах получается неплохо выжимать и по производительности.
А что у Вас за решение на Firebird+Hadoop? Ссылочку можно?
Внутренний продукт :), собираем данные финансовой статистики на основе этого генерируем прогнозы. Краулер собирает данные и отправляет их в ZeroMQ, который раскидывае их на несколько серверов в кольце для дубликации данных (на случай если сервер умрёт — останется копия на другом сервере, на подобии как apache cassandra но с возможностью цеплять Hadoop отдельно к каждому серверу). Отдельно Hadoop — генерирует прогнозы обрабатывая данные из Firebird, при этом отдельно словари храним в Redis при расчётах. В принципе в такой схеме важно уже было удобство работы с базой данных из языка программирования на котором писал система (у нас freepascal + php), а производительность упиралась в производительность i/o, а не базы данных (Firebird или MySQL, PostgreSQL).
Круто :) Не хотите сделать case study для сайта FirebirdSQL.org?
Пока нет NDA :)
Нашёл исходную презентацию на который ориентировались когда делали своё решение — 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
Так же архитектору базы данных и админу желательно иметь под рукой статьи по оптимизации на подобии: www.josh-hartmann.com/firebird-performance-tweaking/ и www.firebirdsql.org/file/community/conference-2014/pdf/16_tpcc_presentation.pdf
Ровно 10 лет назад я вытаскивал из файла БД Firebird 1.x (Interbase 6.x) удалённые данные :) Даже статью написал по этому поводу (всё ещё доступна на сайтах популярных в то время). Не думал, что ещё услышу что-то о Firebird.
Интересно внутренняя структура хранения данных м/у 1.x и текущей 2.5 сильно поменялась?
Интересно внутренняя структура хранения данных м/у 1.x и текущей 2.5 сильно поменялась?
Sign up to leave a comment.
Русская документация по языку SQL СУБД Firebird 2.5