Состоялся (https://www.firebirdsql.org/en/news/firebird-3-0-3-sub-relea.../) релиз реляционной СУБД Firebird 3.0.3 (https://www.firebirdsql.org/en/firebird-3-0-3/), продолжающей развитие кода БД InterBase 6.0, открытого в 2000 году компанией Borland. Firebird распространяется под свободной лицензией MPL и поддерживает стандарты ANSI SQL, в том числе такие возможности, как триггеры и хранимые процедуры.
В новой версии оптимизированы такие операции как слияние дельта-файла с основным файлом БД (инкрементальный бекап), ALTER DOMAIN при наличии большого количества зависимостей от домена, сброс грязных страниц на диск. В getInfo() обеспечен вывод дополнительной информации о сжатии и шифровании. Ускорено резервное копирование при помощи nBackup на внешние разделы NAS поверх SMB. В Firebird 3.0.3 также устранена уязвимость (http://tracker.firebirdsql.org/browse/CORE-5735), при которой владелец дополнительного ключа может создавать неавторизированные соединения к зашифрованной БД.
URL: https://www.firebirdsql.org/en/news/firebird-3-0-3-sub-relea.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=48021
А зачем она нужна, если есть postgresql, mariadb, mongodb, clickhouse и sqlite?
Зачем mariadb, если есть postgresql?..
Зачем mongodb, если есть postgresql?..
Зачем clickhouse, если есть postgresql?..
Зачем sqlite, если есть postgresql?..
А зачем postgresql?..
>Зачем mariadb, если есть postgresql?..не нужна
>Зачем mongodb, если есть postgresql?..
для данных с нечёткой схемой.
>Зачем clickhouse, если есть postgresql?..
для анализа временных рядов в бигдейте
>Зачем sqlite, если есть postgresql?..
быстрая - нет оверхеда на синхронизацию.
>>Зачем mongodb, если есть postgresql?..
> для данных с нечёткой схемой.С версии 9.4 postgresql поддерживает данные с нечёткой схемой!.. ;)
>С версии 9.4 postgresql поддерживает данные с нечёткой схемой!.. ;)1. Монга появилась раньше.
2. Как JSON* приделан к Слону - да идите вы обратно откуда пришли. Хотя если ни разу не увидеть Монго, то кому-то может и понравится.
Фсе девочки знают что монга - оно!"Mongo writes are not reliable. While most go through, it is never guaranteed that update succeeds or not and you have to manually query database to check if it did."
Если ты не поняло - это цитата из приговора вынесенного кровавым Ынтерпрайзом :)Это конечно не значит что монгу там вообще не юзают, но юзают ея для сбора всякой фигни, которая даже если и пол-дня лежит, то воет только мониторинг :-)))))
ага, ссылка за 2010 год, сейчас всё гораздо лучше. кто там седьмой постгрес вспоминал?
> ага, ссылка за 2010 год, сейчас всё гораздо лучше. кто там седьмой
> постгрес вспоминал?2010 это pg 9.0
>Mongo writes are not reliable
>это цитата из приговора вынесенного кровавым Ынтерпрайзомкло^WЭксперты опеннета такие эксперты.
OTOH, Mongo writes are not reliable. While most go through, it is never guaranteed that update succeeds or not and you have to manually query database to check if it did.
answered Jul 26 '12 at 11:36
Oleg V. VolkovБоже мой, разве Олег Волков со стэковерфлоу в 2012м мог ошибаться?! Срочно сношу монгу со всех серверов.
в 2012м - не мог
ага, там в 2013 починили эти проблемы
Я тебе конечно верю, но вот ссылочку на Ъ былобы ЗБС. Хозяйство не моё самому искать влом.
Ну и ещё: наш монговщик как был несчастным тогда, так и сейчас не весел --> вы всё врёти! :)
https://stackoverflow.com/a/10582522/6162139
> Ну и ещё: наш монговщик как был несчастным тогда, так и сейчас не весел --> вы всё врёти! :)Как обычно на опеннете, ты Монгу и в глаза не видел, но кукарекаешь против?
Монга, что 3.4, что 3.6 полностью проходит тесты Джепсенов. Ты конечно и не в курсе что это такое.
Постгрес эти тесты проваливает.
А Firebird, судя по всему, вообще никому не нужен, не тестировался.
>Как обычно на опеннете, ты Монгу и в глаза не видел, но кукарекаешь против?Я тебе + поставил - разъярённая жаба которая кукарекает "за" - это доставляет :-р
>Монга, что 3.4, что 3.6 полностью проходит тесты Джепсенов.
Ух ты! А старая - не ...
>Ты конечно и не в курсе что это такое.А ты уже перестал бить и забирать пенсию у мамы-пенсионерки? (С) :)
А чЁ - я тоже просто предположил(С)
>Постгрес эти тесты проваливает.Но при этом он остаётся продакшен левел рдбмс, а монга - оно для уютных чатегоф :)))
>> Ну и ещё: наш монговщик как был несчастным тогда, так и сейчас не весел --> вы всё врёти! :)
> Как обычно на опеннете, ты Монгу и в глаза не видел, но
> кукарекаешь против?
> Монга, что 3.4, что 3.6 полностью проходит тесты Джепсенов. Ты конечно и
> не в курсе что это такое.Конечно, нет. Но я поискал пару минут.
" About Jepsen
Jepsen is an effort to improve the safety of distributed databases, queues, consensus systems, etc. " --http://jepsen.io/
+
" This fall, I worked with MongoDB to design a new Jepsen test for MongoDB. We discovered design flaws in the v0 replication protocol, plus implementation bugs in the v1 protocol [...] " --https://aphyr.com/posts/338-jepsen-mongodb-3-4-0-rc3+
" 3. Любая технология имеет слабые и сильные стороны. Скорее всего, сейчас вы сосредоточены только на сильных. MongoDB может очень круто скейлиться, но насколько это реально удобно жить без [...]9. Велика вероятность, что вы решаете новым модным инструментом не ту задачу. У многих компаний не такой уж highload для использования NoSQL решений. Обычный PostgreSQL с репликами и, возможно, небольшим ручным шардированием, решит задачу куда лучше, чем этот ваш [...ой...]. " --https://eax.me/avoid-new-toys/
> Постгрес эти тесты проваливает.
> А Firebird, судя по всему, вообще никому не нужен, не тестировался.
>У многих компаний не такой уж highload для использования NoSQL решенийУ Монги не только скорость в достоинствах.
>новым модным инструментом не ту задачу
Очередная статейка от 2010? Я пару проектов поднял на монге в 2015 и 2016, когда она уже была более чем mature.
А сейчас так вообще 2018-й идёт.
>ов поднял на монге в 2015
> А сейчас так вообще 2018-й идёт.Ну, неси её на помо*ку, не тормози.
> 1. Монга появилась раньше.2009 год
Schemaless hstore в postgres — 2006 год.
>> 1. Монга появилась раньше.
> 2009 год
> Schemaless hstore в postgres — 2006 год.А в 1998 году в Слона можно было засунуть XMLку в varchar. Вау, Слон вскукарекнул раньше всех.
Но в 2018м почему-то работать с Mongo на порядки продуктивнее, чем со Слоном...
В какой из банков успешно внедрили? :-))))
Ах вы о чатегах ... тады ДА! Лютая вешшь для этого! :-)))
>>Зачем mariadb, если есть postgresql?..
>не нужнавот им расскажите: https://eng.uber.com/mysql-migration/
это уже давно обсудили и обсосали, сейчас да и по большей части ранее, это уже не актуально.
актуально-актуально. если вам надо хотя бы десятки тысяч одновременных соединений, брать постгрес -- это дурка, вам любой dba расскажет (если он с постгресом работал -- ещё и расскажет, чем плох pgpool, например). mysql тащит такое на одном хосте. но там другие проблемы, да.
PgBouncer если вам столько открытых сессий держать нужно.
тс.. не спугните эксперта с пгпулом в 2018..
уже лет шесть с ним знаком. для ряда юзкейсов лучше, чем ничего, а для ряда не спасает.
почитайте его (pgbouncer) багтрекер. у mysql серьёзно лучше реализован пулер.
Десятки тысяч коннектов к DB ... да у них архитект заодно жена хозяина, любое его решение априори - правильное! :-) А здешние обезьянки "уже сделали выводы космической величины и ..." (С) Собачье СердцеВ результате у них тыЩЩи инстансов мыскля, каждый ранится в ... докере(sic!) и цырк с костылями и воздушними акробатами при подъёме каждого инстанса ...
Как всё это хоть как то работает - чёрная мля магия %-\ (Или оракел где то в секретных подвалах гес* :-))))) Шутка. )
да нет никакой серебряной пули. просто бывают юзкейсы, для которых постгрес не показан, это вам расскажет любой dba. впрочем, тех, для которых показан, на практике таки больше.
А зачем мне рассказывать то, о чём я и сам знаю? :-)
Речь с броневичка была о том что юберы сменили неудачное тех решение на другое, ну может чуть менее неудачное ... и ставить их в пример ... ну ты понел :-)
> А зачем мне рассказывать то, о чём я и сам знаю? :-)
> Речь с броневичка была о том что юберы сменили неудачное тех решение
> на другое, ну может чуть менее неудачное ... и ставить их
> в пример ... ну ты понел :-)это было антитезой на юношеский максимализм вида "mysql не нужен, postgres наше всё". нифига, есть случаи, где постгрес не возможен из-за его архитектуры. их меньшинство, но периодически бывают.
не надо мне по третьему кругу рассказывать про архитектора-дурака и middleware, почитай коркодила, если уберу не веришь. ссылка ниже по треду.
"profession de foi" ...(C)
Давай расставим точки над Ё - я очень уважаю слоника. Он мне тупо денег принёс :-р
Но я нигде не утверждал что для убера оно лучше. Даже переделанная их архитектура, но со слоном - была бы __хуже__ По вполне понятным причинам. Да им RDBMS, как таковая, вообще не нужна! Они и дельфинку как тyпoй сторидж юзают :)
Но программисты (чтоб сделать специализированный стремительный домкрат) - дороги, а железо дёшево. И мы снова наблюдаем победу мощности движка над аэродинамикой (С)Как то так.
> уже лет шесть с ним знаком. для ряда юзкейсов лучше, чем ничего,
> а для ряда не спасает.
> почитайте его (pgbouncer) багтрекер. у mysql серьёзно лучше реализован пулер.А ещё лет через десять можешь ознакомиться с 3tier-архитектурами :)))))
Надо вводить обязательную регистрацию, причём с реальными ФИО и ссылкой на HH, может тогда у некоторых экспертов опеннета пропадёт желание ахинею писать.
ещё раз внимательно читаем коркодила из ссылки ниже. а уже потом делаем предположения, кто из собеседников с чем не знаком. нет никакой серебряной пули. и постгрес ваш тоже не она.
>Надо вводить обязательную регистрацию, причём с реальными ФИО и ссылкой на HH, может тогда у некоторых экспертов опеннета пропадёт желание ахинею писать.Ну явные тролли отпадут, это да.
А что делать с такими как ты?
Ведь чувствуется что ты искренне веришь в то о чем пишешь ... но ахинеей от этого Ваши труды, проф. - быть не перестали :)
(Я не для наезда, а для ясности. Ты можешь тоже самое говорить о моей нетленке :) )Так что я думаю как сейчас - и есть самое сбалансированное состояние.
А что, postgresql можно использовать как sqlite?
Davno
То, что существуют _сторонние_ реализации embedded postgres, вовсе не означает, что он действительно может использоваться как замена sqlite.
>А что, postgresql можно использовать как sqlite?А из булки хлеба можно сделать троллейбус (С)
> Зачем mariadb, если есть postgresql?..Затем, чтобы не вакуумить базу с мейнтенансом каждый раз.
> Зачем mongodb, если есть postgresql?..
Для шустрого доступа к документам с нечёткой структурой, и чтобы не вакуумить.
> Зачем clickhouse, если есть postgresql?..
Не пробовал. Подозреваю, что чтобы не вакуумить.
> Зачем sqlite, если есть postgresql?..
В качестве embedded БД с минимальным оверхедом для приложений, которым не нужен выносной движок.
> А зачем postgresql?..
Не буду троллить.
>чтобы не вакуумить базу с мейнтенансом каждый раз.До сих пор на 7.* ? Ну респект конечно, но со времён Чапаева много блин изменилось :)
вот умный человек про 9.6 пишет https://plumqqz.livejournal.com/499009.html
да-да, со времен 7 изменилось что в каждой новой версии нам торжественно заявляют "vacuum больше не нужен" и "мы его скоро-скоро вообще выпилим из cli". Помнится, к выходу десятой тоже заявляли. А воз и ныне там - vacuum full и reindex наше всьо, поскольку структуру хранилки с 95го года никак нельзя переделать.
... у всех свои недостатки! (С) В джазе только девушки
:-)
>>чтобы не вакуумить базу с мейнтенансом каждый раз.
> До сих пор на 7.* ? Ну респект конечно, но со
> времён Чапаева много блин изменилось :)Эксперты, такие эксперты. В 9.7 всё то же самое. Причём на одном сервере база выросла до 80% storage-а, вот пришлось поприседать чтобы завакуумить.
Ещё и эпической жирноты айсберги в виде "delete на LOB на самом деле не удаляет LOB, а надо чистить ещё какую-то системную таблицу с перезапуском Слона в какой-то специальный режим".
>>>чтобы не вакуумить базу с мейнтенансом каждый раз.
>> До сих пор на 7.* ? Ну респект конечно, но со
>> времён Чапаева много блин изменилось :)
> Эксперты, такие эксперты. В 9.7 всё то же самое.найдёшь мне в списке релизов постгреса 9.7, "эксперт"? https://www.postgresql.org/support/versioning/
Что поменялось от того, что на этом серваке 9.6? Вакуум стал не нужен?
нет, просто теперь всем стало очевидно, что кто-то звездит или серьёзно ошибается в фактах.
> нет, просто теперь всем стало очевидно, что кто-то звездит или серьёзно ошибается
> в фактах.Не. Он не ошибается и не звездит. Просто сервер опеннета стоит на пересечении множества миров.
А он из той самой реальности, где тормозную и жрущую память сишку с плюсами обгоняет жаба, на которой пишут используемые ОСи и дрова. Заодно и версии постгреса немного другие.
> нет, просто теперь всем стало очевидно, что кто-то звездит или серьёзно ошибается
> в фактах.Ты звиздишь и тот чепушило, писавший "вакуум был только в 7-м слоне при Чапаеве". Ибо в 9.6 оно никуда не делось. И про удаление LOBов актуально для 9.6.
Есть что по делу сказать или ты такого слова не знаешь?
FireBird в этом строю занимает своё достойное место. Полнофункциональная, не такая монструозная как PG, применяется в немалом числе программно-аппаратных комплексов, в т.ч. у военных и госорганов, прекрасно по-русски документирована, имеет производительные ODBC-драйверы, вот-вот станет учебной СУБД в школах и ПТУ (встроена в LibreOffice 6).
>FireBird в этом строю занимает своё достойное местоОгласите пожста ТОП5 доводов за Firebird (vs Postgres).
Из того что нравится:
Простота администрирования.
Удобный синтаксис.
Есть полноценный embed с прозрачной миграцией на сервер.
IBExpert (ну удобный он ;) )
Быстрая(очень быстрая) вставка без лишних накладных расходов.
Доводов именно за FB против PG нет. Продукты в одном ряду. PG мощнее, сложнее. Если вам нужен хоть один довод, то вот он: у PG документация больше по объему.
В девичестве, как InterBase, была весьма скромная к ресурсам база, без необходимости администрирования. Собиралась инсталляция продукта + инсталл InterBase = продукт в проде у клиента.
Предположу, что Вы "писатель" и сравнить 2 продукта для Вас неподъёмная задача.
> не такая монструозная как PGОракл, вы видимо, и не видели? PG ставится одним пакетом в любом актуальном дистрибе, по желанию home поменять и готово.
Огласите критерии монструозности.
Оракл не осилили упаковать в пакеты (нормально упаковать, а не как есть). Да им и пофиг, в общем-то. Да и поддержку проще продавать.
Несомненно Oracle занимает в списке монструозных СУБД достойное первое место, по возможности избегайте её. Если так хочется коммерческую СУБД то лучше уж Sybase или недавно портированный на Linux MS SQL Server.
> Несомненно Oracle занимает в списке монструозных СУБД достойное первое место, по возможности
> избегайте её. Если так хочется коммерческую СУБД то лучше уж Sybase
> или недавно портированный на Linux MS SQL Server.Второе. IBM DB2 забыли.
> Несомненно Oracle
> избегайте её. Если так хочется коммерческую СУБД то лучше уж Sybase
> или недавно портированный на Linux MS SQL Server.Только оракл пошустрее их
>Несомненно Oracle занимает в списке монструозных СУБД достойное первое место, по возможности избегайте её.Зачем? В установке и настройке оракела нет ничего такого с чем бы не справился любой инженер с мозгами, а не с эмулятором. Тонкости оставим экспертам, но "средне-температура-больничный инстанс(Tm)" - поднимет любой пиoнep.
Самый большой недостаток орукукуля, из за которого я в 2007-2010 имел хорошее боковое бабло переводя конторы на слоника - это его цена. Оно немилосердо дорого :(
Это если по-чесноку, если не врать "про швaбoду" и пр.
>Если так хочется коммерческую СУБД то лучше уж SybaseНу да - ни админов, ни проггеров с опытом работы С ...
Зато то ты не такой как все! Удачи! :)
>или недавно портированный на Linux MS SQL Server.Ещё не щупал, но уже страшно :-))))
> PG ставится одним пакетом в любом актуальном дистрибе, по желанию home поменять и готово.Как-то раз захотел поставить потыкать вместо MySQL, оказалось оно ещё от системной базы юзеров зависит и нельзя (или можно, но относительно сложно) просто создать юзеров на уровне самой БД. Это философски очень правильно и красиво, но мягко говоря не совсем практично IMHO.
одним словом: RTFM
Неправда ваша, как раз не зависит (кроме одного учётника для запуска сервиса).
Кроме того, ПГ имеет вариант с распределённой обработкой (но сам я его не пробовал!)
>оказалось оно ещё от системной базы юзеров зависит и нельзя (или можно, но относительно сложно)Да практически так же как в мыскле! Но да, голову по-минимуму - но надо. Это тебе не рукоблудить :-)
> встроена в LibreOffice 6Внезапно. Интересно чем обусловлен такой необычный выбор, почему не SQLite...
Очень правильный вопрос.
Хотя вроде как sqlite уже давно можно было тыкать в офисах
> Очень правильный вопрос.
> Хотя вроде как sqlite уже давно можно было тыкать в офисахФайрбёрд ищет популярности. Нет, скюлайт полноценно не работает в ОО (не работал?) В 3-ке -- точно нет.
> Нет, скюлайт полноценно не работает в ОО (не работал?) В 3-ке -- точно нет.SQLite можно полноценно использовать в Win/Lin в OpenOffice3-4-5 и LibreOffice 4-5-6 через ODBC-драйверы уважаемого Кристиана http://ch-werner.de/sqliteodbc/
Правда он начал его подзабрасывать, SQLite там 3.15.2 (а свежая 3.22), а фишка с подменой sqlite3.dll работает не всегда.
Другие варианты - заплесневевший адаптер 2008-го года и доступ через Python из состава OpenOffice|LibreOffice - не могут считаться удобными.
>> Нет, скюлайт полноценно не работает в ОО (не работал?) В 3-ке -- точно нет.
> SQLite можно полноценно использовать в Win/Lin в OpenOffice3-4-5 и LibreOffice 4-5-6 через
> ODBC-драйверы уважаемого Кристиана http://ch-werner.de/sqliteodbc/Возможно, полноценно работать стало с 4-кой и 5-кой, я не пробовал. В крайней 3-ке нужно было всё до-ставлять самому, и тогдашний jdbc xerial-овский не работал, а кристиановский jdbc валил ОО. Кристиановский Odbc работал-таки, но чего-то не делал, а также кидал непонятные ошибочки.
> Другие варианты - заплесневевший адаптер 2008-го года и доступ через Python из
> состава OpenOffice|LibreOffice - не могут считаться удобными.Да, доступ "должен" работать через штатные механизмы.
>> встроена в LibreOffice 6
> Внезапно. Интересно чем обусловлен такой необычный выбор, почему не SQLite...Рискну предположить:
SQLite - прекрасная, но однофайловая БД, с чтением на основе меток внутри файла. При 3-х коннектах (а они идут по протоколу SMB/NFS) - она работает ещё терпимо (как MS Access при 5-ти), но при 10+ - таймаут начинает злить.
FireBird - все-таки клиент-серверная СУБД, обслуживаемая отдельным не ОС-процессом, которая и при 10, и 100+ коннектах ведет себя "ровно".
Но SQLite тоже нужна в LO, поскольку 0-администрирование СУБД - это +100% времени на изучение самой СУБД и написание полезных SQL-запросов.
> не такая монструозная как PGмонструозная, я так понимаю, мегабайт с 6 начинается?
Установил свою прогу. в 2003г в гос конторе с InterBase,
в последующем перевел на Firebird.
Где-то в 2012 мне сказали, что программа не работает. Оказывается
админы снесли сервер с БД (база проработала около 10 лет без администрирования и
обслуживания). Прога трудится до сих пор (размер баз в 2012 был порядка 6 Гбай),
без моей участи и без участи админов по БД.
Просто на этом сайте наяривают на технологии, и забывают, что технологии должны служить выполнению реальных задач и потребностей.Если программа без администрирования проработала 10 лет - то это очень хорошая программа. И кто бы что тут не говорил, что X лучше Y, а Y лучше, чем Й. Этим людям просто заняться нечем.
Просто кто-то трындит. Оно прекрасно рассыпалось на любой чих и пук. Ни одна СУБД не приносила столько боли
> Просто кто-то трындит. Оно прекрасно рассыпалось на любой чих и пук. Ни
> одна СУБД не приносила столько болида нет, все так обычно и бывает - никому не нужная БД (размер не имеет значения, может они там нежатые факсовые тифы хранили), в программу, работающую с которой, заглядывают раз в пол-года, один человек, который еще вообще помнит, что она у них есть, вполне способна протарахтеть и 10, и 20 лет, пока в древнем сервере конденсаторы не полопаются, и еще сколько-то даже после того, на эпизодическом пинании ресета.
Раз "админы снесли", значит именно так оно и было - архинужнейшая и архиполезнейшая высоконагруженная база, про которую админы даже не знали, что она существует или что ей еще кто-то пользуется, ага, поверил.
Да система не высоко нагружена. Несколько тысяч абонентов присылают
месячную/квартальную/годичную отчетность (порядка 10 видов).
Под подобную нагрузку и подбирал БД.
На счет никому не нужная, не знаю, но аналитика выдаваемая прогой (срезы OLAP)
постоянно висят на сайте конторы, да и финансовые показатели думаю не безразличны
конторе.
> Да система не высоко нагружена. Несколько тысяч абонентов присылают
> месячную/квартальную/годичную отчетность (порядка 10 видов).
> Под подобную нагрузку и подбирал БД.
> На счет никому не нужная, не знаю, но аналитика выдаваемая прогой (срезы
> OLAP)
> постоянно висят на сайте конторы, да и финансовые показатели думаю не безразличны
> конторе.о, я такое когда-то чинил (к счастью, не снес неглядя, как те админы). Не то что бы оно было безразлично (еще как интересовало контору), но пользовались этим реально полтора человека - и еще пять из пары сот сотрудников вообще знала о существовании явления (кому-то может прилетало по горбу по результатам тех графиков, но они вряд ли были в курсе, откуда дровишки).
Когда его наконец-то сломали, заменив не полнофункциональным аналогом в другом месте (оно там брало данные с прода, доступаясь к ним через феерический анус), никто особо не плакал.
В любой теме про давно работающие программы должен появиться человек, который скажет:
"А я когда-то александрийскую библиотеку сжёг, никто особо не плакал."
У Вас аура(руки) кривая. interBase если и падал, то весьма и весьма редко, ибо ломаться там особо нечему - запись либо есть в базе, либо её нет. Стоит отметить, что восстановление данных после падения хоть и редко, но приводило к потере данных. А это уже при совсем плохой ауре - бэкапы, если был админ, однако.
А так, у конторы клиенты были по всей России с нулевым администрированием.
> А зачем она нужна, если есть postgresql, mariadb, mongodb, clickhouse и sqlite?Отличный вопрос. Заминусовали, нафлудили, но никто так и не ответил. Специфика каждой из перечисленных СУБД и для каких задач они больше подходят довольно понятна, а вот чем от них отличается Firebird и в каких задачах/конфигурациях (кроме портирования старого Delphi-софта) она выигрывает перед остальными и почему - непонятно, но интересно. По слухам вроде хранимыми процедурами она красна, для интеграции логики в БД чтобы не плодить middleware (но чем конкретно хранимки в ней лучше чем в других - хз).
открываешь любую книгу по FB и читаешь, что не рекомендуется использовать хранимки, т.к. перфоманс умирает
О! Круто видеть человека, читающего по FB аж прямо книги. Ну ясно. Значит не в хранимках прикол. Может вы подскажете тогда какая у FB киллеp-фича и какие слабости? Ни кто же не говорит, что она не нужна, просто сравнительно экзотическая в наше время вещь и народ нуждается в понимании с чем её едят и по каким поводам.
> FB киллеp-фича и какие слабости? Ни кто же не говорит, чтокиллeр-фича одна - условно-совместима с interbase (всего пол-дня траха и чтения чьей-то чуши в гугле, и можно перенести данные).
А поскольку откопать обратно того программиста, который в 2001м году эту хрень понаписал, сложно и бесполезно, он уже разложился, проще раз в месяц, когда понадобится, включать ту пыльную машину с winXP в дальнем углу, на которой еще запускается клиент.
Ну да, на дельфи, на чем еще.
> открываешь любую книгу по FB и читаешь, что не рекомендуется использовать хранимки,
> т.к. перфоманс умираетИменно книгу? И по какой версии?
Опять-таки, взвешиваем и оцениваем ситуацию, делаем выводы, принимаем решение, использовать хп или нет. Штука удобная. Порой бывает необходимо решить какую-то задачу, так что мне, сразу программу писать? А так накидал запросы в хп, обработал данные , получил результат и удалил нахрен хп - и перфоманс не страдает ))
> кроме портирования старого Delphi-софтаЕсли уж портировать - так можно заодно и переписать на что-то более человеческое.
Вы имеете в виду Free Pascal?
Например - замена эмбеддед версии на клиент-серверную с одного тычка
Месяц назад выбирал СУБД для своего наколеночного проекта. MySQL с дефолтными настройками - 120 с лишним мегабайт ОЗУ. PostgreSQL - в районе 40, точно не помню, но зато постоянно чем-то занимала процессор. Firebird - 10-20 мегабайт в памяти и практически нулевая нагрузка на процессор. SQLite по определенным причинам не подходил.
Я понимаю, что любую перечисленную можно настроить под свои нужды. Но всё же.
Есть сравнение с другими, чем она лучше?
> Есть сравнение с другими, чем она лучше?Слышал, что активно применяется для миграции на линукс наследственных приложений с тех же дельфей.
> Есть сравнение с другими, чем она лучше?///---wiki
- Соответствие требованиям ACID.- полностью поддерживает SQL-92 Entry Level 1 и реализует большую часть стандарта SQL-99.
- работает на аппаратных платформах x86, x64 и PowerPC, Sparc и многих других, и поддерживает легкий переход между этими платформами.
- поддерживает множество способов доступа, включая: собственные наборы компонент для C/C++, Delphi, классы для ADO, ODBC, JDBC (Jaybird), драйверы для Python, PHP, драйвер OLE DB, dbExpress, провайдер данных .NET и прямой доступ с использованием клиентской библиотеки сервера (fbclient.dll или GDS32.dll)
- поддерживает большие базы данных. Теоретический предел в настоящее время составляет 64 TБ для одного файла базы данных.
- форк «Ред база данных» сертифицирован ФСТЭК России и соответствует отечественным требованиям защиты информации, проходит жесткое тестирование и при этом совместим на уровне резервных копий с основной веткой разработки.
---///
Любой админ FB, чья база выросла хотя бы до 2Тб уже давно имеет седины
А что оно до сих пор невосстановимые бэкапы делает??!?! Сомнительно, хотя ... 8-)
> А что оно до сих пор невосстановимые бэкапы делает??!?! Сомнительно, хотя ...
> 8-)как минимум, даже "восстановимый" бэкап 2T восстанавливается достаточно долго, чтобы седых волос у тебя заметно прибыло. А учитывая, что мало у кого из адептов этой хрени есть _еще_ 2T для экспериментальных восстановлений с проверкой, что именно там восстановилось...
А что, если перейти с firebird на pgsql, волшебным образом появятся "еще 2T для экспериментальных восстановлений"?
> А что, если перейти с firebird на pgsql, волшебным образом появятся "еще
> 2T для экспериментальных восстановлений"?да нет, просто не будет плохих снов о том, что энцать версий назад вывод pg_dump, внезапно, оказался не базой, а тыквой. Но 2T база pgsql, в общем-то, тоже к спокойному сну никак не располагает.
Да ты и с оракаловым рэком совсем уж спокойно спать всё равно не будешь.
Ну у этих, хоть и задорого, но можно купить всяких плюшек бдляЪ ...
Ну то есть SQLite3 её может заменить только в путь.
SQLite3 не поддерживает клиент-серверный режим по сети и блокирует файл от других процессов при записи в БД. То есть SQLite3 - это встраиваемая СУБД с монопольным доступом на запись. Firebird работает с несколькими транзакционными моделями, например, даже тогда, когда данные могут не блокироваться от модификации при доступе к базе из нескольких процессов.
> SQLite3 не поддерживает клиент-серверный режим по сети и блокирует файл от другихто есть ненужного протокола (написанного специалистом по тазам банных - т.е. как правило либо плохого, либо с дырой вместо аутентификации, либо то и другое сразу, и все бережно завернуто в openssl)
> процессов при записи в БД. То есть SQLite3 - это встраиваемаячудес не бывает, ни одна таза банных не умеет писать в одно и то же место (это не обязательно "файл") из двух процессов - "такая фигня получается!"
> СУБД с монопольным доступом на запись. Firebird работает с несколькими транзакционными
> моделями, например, даже тогда, когда данные могут не блокироваться от модификации
> при доступе к базе из нескольких процессов.не могут. Это называется "транзакционная целостность".
Просто то, что в случае sqlite, решается банальным lockf, и ожиданием других процессов, в случае "больших" баз может решаться постановкой запросов в очередь единственного процесса (а чаще то и другое - пул процессов плюс взаимный локинг). Что совой об пень, что пнем о сову - пока данные не запишутся на диск, сообщить сказавшему 'commit' об успешном завершении (или дать ему по морде forced rollback'ом, если пока он копался, данные протухли) мы не можем.у других есть еще всякие гранулярные локи, но выигрыш от них, как правило, преувеличен, по сравнению со сложностью реализации.
А "транзакционные модели" вида immediate/exclusive/deferred есть, не поверишь, и у sqlite. row locks вот нету, не очень и нужны.
Ты пошутить решил?Как самый-самый минимум - "большие" сервера лочат таблицы, а не базу целиком. А обычно - даже не таблицы, а диапазоны, и тем более - когда речь идёт о версионниках, которыми являются, считай, все современные СУБД.
> Как самый-самый минимум - "большие" сервера лочат таблицы, а не базу целиком. А обычно - даже не
> таблицы, а диапазоныты реально не отличаешь внутриsqlевые "локи" от логики физической записи на диск?
Ты ж не думаешь, что в больших БД действительно все транзакции последовательно идут и сразу на диск пишутся? А у sqlite - да, гранулярность - вся база.
Физическая запись какого рода имеется ввиду? В редо-логи, ундо-логи или в сами таблицы?
> Физическая запись какого рода имеется ввиду? В редо-логи, ундо-логи или в сами
> таблицы?и в чем великая разница?
Как бы это тебе сказать то ... в кровавом они как минимум на разных девайсах :-)
Причём сами таблы - всё ещё на блинах, а вот другие - на другом :)
Дальше объяснять?
>> Физическая запись какого рода имеется ввиду? В редо-логи, ундо-логи или в сами
>> таблицы?
> и в чем великая разница?Как минимум в частоте записи. Сохранять данные после каждого комита дорого. Поэтому для устойчивости придумали редологи, что позволяет сами данные сохранять нечасто. А сами надо то в силу простоты имеют высокую производительность. И уж точно не является скрытой блокировкой, об утверждении которой и началось обсуждение, тк запись в редо независима и не требцет никаких блокировок.
>не могут. Это называется "транзакционная целостность".
>Просто то, что в случае sqlite, решается банальным lockf, и ожиданием других процессов, в случае >"больших" баз может решаться постановкой запросов в очередь единственного процесса (а чаще то и >другое - пул процессов плюс взаимный локинг). Что совой об пень, что пнем о сову - пока данные не >запишутся на диск, сообщить сказавшему 'commit' об успешном завершении (или дать ему по морде forced rollback'ом, если пока он копался, данные протухли) мы не можем.
>у других есть еще всякие гранулярные локи, но выигрыш от них, как правило, преувеличен, по >сравнению со сложностью реализации.Наглядный пример воинствующей некомпетенсности.
Нахрена огнептаху клиент-сервер, если его большинство всё равно гоняет рядом с приложением?
не, не может - "сертификация ФСТЭК" это вам не хухры-мухры.
Ай, ну объявится какой-нибудь местный Firebird Pro. Был бы спрос.
> не, не может - "сертификация ФСТЭК" это вам не хухры-мухры.Если увидится спрос и выгода "сертификаторам" - сразу же сертифицируют.
> Ну то есть SQLite3 её может заменить только в путь.Да не, слишком много в софте реализовать придётся ( т.е. дорого ) и в случае если перерастёт уровень 1 компа, то переписывание всего софта
> Да не, слишком много в софте реализовать придётся ( т.е. дорого ) и в случае если перерастёт
> уровень 1 компа, то переписывание всего софталюди, "перерастающие уровень 1го компа" и НЕ переписывающие свой софт (часто заодно с полным переделыванием и структуры данных тоже) - вынуждены будут делать это ненамного позже, с характерным результатом в виде получения интенсивной любви от пользователей их продукта.
А если софт все равно переписывать - то в общем-то никто не мешает нарисовать правильный mid-layer, который и будет заниматься общением с базой. Как, в общем-то, в правильном софте и принято. А на то что субд заменит тебе нормальное проектирование софта для многоюзерской параллельной работы, надеются только кое-какеры и неудачники.
(были времена, когда это действительно было так, но, к сожалению, давным-давно прошли. А то б кругом был один oracle на мега-кластерах)
Есть дофига применений "между". Собственно, все базочки для мелких контор из этого "между". Где совершенно тупого выноса базы из embeddded в отдельный сервер (при условии рефелекторного примененения транзакций при написании софтины) достаточно, чтобы из однопользоватлеьской аппы сделать "многопользовательскую" - то есть нормально работающую на 3-5-10 человек, шуршащих без особой интенсивности. А больше - и не надо. С другой стороны, пока юзер один - можно не заморачиваться созданием и поддержкой отдельного сервера БД, который должен быть включён, доступен и не пинаем уборщицей.А если о вебе говорить - так там вообще масштабирование в пределах трёх порядков решается костылями из кэшей. Бардак выходит, но более-менее живой и приносящий деньги владельцу
> Есть дофига применений "между".сделанные я-у-мамы-программисом по рецептам, найденным на stackoverflow ("хотя бы из ответа, или из вопроса?")
> Собственно, все базочки для мелких контор из этого "между".
совершенно необязательно. Кто-то покупает готовое решение нужного размера, кому-то везет и на него работает нормальный разработчик, кто-то вынужден таких нанимать, потому что контора мелкая, а база нифига и не мелкая.
А дальше - кому как повезло. Но если было сделано на чем-то обычном, pg/mysql/да хрен с ним, ms, наконец - обычно наследники могут как-то это все поднять, без особых проблем. Иногда даже и улучшить что-то.
А ходить вокруг сдохшего overengineered монстра, выбросившего тебе ora-0006, можно вечность, без особых успехов. Или мучительно пытаться поапгрейдить уже толком неживую систему аж на one true interbase (c) borland на что-то, хотя бы не требующее библиотек и дистрибутива 2001го года выпуска.
(и главное, вроде ты все это и починил в конечном итоге, но осадочек-то остается)> Где совершенно тупого выноса базы из embeddded в отдельный сервер (при условии рефелекторного
> примененения транзакций при написании софтины) достаточно, чтобы из однопользоватлеьской аппы
> сделать "многопользовательскую" - то есть нормально работающую на 3-5-10 человек, шуршащих безты не поверишь, мы трахались с такой "многопользовательской" аппой в далеком 95м году. Она даже и работала - пока их было 3-5-10 (без всякого отдельного сервера, попутно и ресурсы жрала не с одного сервера, а с многих клиентов разом, по тем временам гораздо более дешевое решение). А как стало 20 - наступили опаньки, и отдельный сервер ничему не помог. И пришлось все переделывать с нуля и нормально - потому что и сама база, спроектированная на трех юзеров и небольшой объем, оказалась нафиг неоптимальна для двадцати и совсем других масштабов.
> А если о вебе говорить - так там вообще масштабирование в пределах
> трёх порядков решается костылями из кэшей. Бардак выходит, но более-менее живойуныло глядя на висящие GET LOCK ... в processlist (как ты понимаешь, ни разу не sqlite, хотя вот этому уроду вполне бы хватило) - нихрена оно не решается :-(
> и приносящий деньги владельцу
и хде тут мой мильен? А, вот он...уп-с, нет, это счет от провайдера...
> Да не, слишком много в софте реализовать придётся ( т.е. дорого )
> и в случае если перерастёт уровень 1 компа, то переписывание всего
> софтаЕсли делать без абстракции - да. А если с абстракцией - то no problem, мимимальные правки в единичных неабстрагируемых запросах. Ну и в софте там "много" реализовывать нечего, тот же SQL.
> Если делать без абстракции - да. А если с абстракцией - тоты вот точно ради базы на одно лицо будешь пихать в код какие-то "абстракции" и универсальный бд-независимый midlayer?
> no problem, мимимальные правки в единичных неабстрагируемых запросах. Ну и в
> софте там "много" реализовывать нечего, тот же SQL.пока не натыкаешься на несовместимость нестандартных типов, или на банальный 'autoincrement'.
>> Если делать без абстракции - да. А если с абстракцией - то
>ты вот точно ради базы на одно лицо будешь пихать в код какие-то "абстракции" и универсальный бд-независимый midlayer?Я думаю он всего лишь об ORM. Я уж 100 лет не видел жабщика который сам SQL рисует. Есть же Hibernate! Причём оно умнее програмизда, ну и чего мучиЦЦо?! :-)
> - Соответствие требованиям ACID.Большинство СУБД
> - полностью поддерживает SQL-92 Entry Level 1 и реализует большую часть стандарта SQL-99.
Большинство СУБД
> - работает на аппаратных платформах x86, x64 и PowerPC, Sparc и многих других, и поддерживает легкий переход между этими платформами.
PostgreSQL
> - поддерживает множество способов доступа, включая: собственные наборы компонент для C/C++, Delphi, классы для ADO, ODBC, JDBC (Jaybird), драйверы для Python, PHP, драйвер OLE DB, dbExpress, провайдер данных .NET и прямой доступ с использованием клиентской библиотеки сервера (fbclient.dll или GDS32.dll)
libpq.so + 100500 всяких биндингов в том числе для твоей тормозной жавы.
> - поддерживает большие базы данных. Теоретический предел в настоящее время составляет 64 TБ для одного файла базы данных.
https://www.postgresql.org/about/
Limit Value
Maximum Database Size Unlimited
Maximum Table Size 32 TB> - форк «Ред база данных» сертифицирован ФСТЭК России и соответствует отечественным требованиям защиты информации, проходит жесткое тестирование и при этом совместим на уровне резервных копий с основной веткой разработки.
Гнилой аргумент.
> libpq.so + 100500 всяких биндингов в том числе для твоей тормозной жавы.У "моей тормозной Java" есть встраиваемая H2 и Java DB. Зачем ещё что-то "наподобие"?
> Есть сравнение с другими, чем она лучше?Не сказал бы, что лучше/хуже. Скорее, иначе
Умеет в CTE с бородатых времён, в отличие от хвалёного MySQL
Надёжна. Инстансов много, сбоев почти нет
На фоне Oracle Firebird, конечно, тупенький. Хинты не умеет (ему можно скормить план целиком. Слишком грубо). Но можно выкрутиться. Вот заметку рисовал о том, как выкручивался: https://vk.com/wall24359278_4717
Драйвер, как я понял, не умеет в именованные параметры, а только в позиционные. Но враппер на коленке пишется за час. Но, в отличие от драйвера MySQL, этот умеет в prepared statements.
> том, как выкручивался: https://vk.com/wall24359278_4717вот это хрень! ;-)
[я про nested query, остальное-то понятное и предсказуемое, если что ]
> Но, в отличие от драйвера MySQL, этот умеет в prepared statements.Если конкретный драйвер мускула в твоем любимом ЯП не умеет prepared statements, то это не значит, что их нет в стандартном мускульном C API. Может автор драйвера поленился или не смог сделать интерфейс к ним, а может ты просто невнимательно читал доку драйвера.
Она ни лучше и ни хуже - она другая, по сравнению с MSSQL, например, ибо без логов вообще. По крайней мере в виде InterBase. Возможно за лета что-то и изменилось.
Классический ANSI SQL + мощные триггеры пред и пост вставки записи и это в эпоху до миллениума. Когда вышел 2000-й скуль с пиаром появления триггеров в нём - долго смеялся.
Насколько я слышал, блокировка на уровне записи, а не целой страницы.
Миграция с v2 на v3 просто ужасна! Тем кто на техподдержке зарабатывает наверное норм, но вот для рядового админа слишком заморочено получается. В правильной последовательности делать бекапы, ставить обновления и править конфиги. О чем думали разработчики?
> Миграция с v2 на v3 просто ужасна! [...] О чем думали разработчики?Сообщите им об этом, но вообще таким долго болел тот же Pg...
>> Миграция с v2 на v3 просто ужасна! [...] О чем думали разработчики?
> Сообщите им об этом, но вообще таким долго болел тот же Pg...да ну нафиг, никаких "фиксов метадаты" - читаешь внимательно release notes, pg_dump|restore и так семь раз (или сколько там раз в notes несовместимость pg_dump'ов)
то есть если не откладывать апгрейд на десять лет, то вполне себе апгрейдилось без странных приседаний и ненужных знаний о внутреннем устройстве. Если отложить - то с промежуточными остановками на всех несовместимых точках.
Представьте себе, совсем недавно перенёс свои базы с 1.5 сразу на 3. Ну кроме того, что в gbak пришлось добавить параметры -FIX_FSS_METADATA WIN1251 -FIX_FSS_DATA WIN1251, больших трудностей не увидел.
Тоже самое, фикс метадаты и всё.
> больших трудностей не увиделА я вот увидел. FB v2 поддерживал даже очень старые базы InterBase, а v3 капризничает и говорит, что не хотит. Получается, что бекап базы нужно делать ДО того как ставится 3-я версия.
В той же винде поставить одновременно 2 версии СУБД можно, но служба будет всего одна (default instance). А запуск FB v3 в режиме приложения официально поломан. Объяснить простому пользователю, как доустановить еще одну службу (командой в страшной чорной консоли, да), а потом переключаться между второй и третьей версией обычно не выходит...
После решения проблем с основной базой выясняется, что security.fdb тоже не обновился. А еще бывает так, чтобы заработала прога, которую делали 10-20 лет назад для InterBase6... оказывается нужно залезть в конфиги сервера и там пошаманить.
Для более-менее админа или службы техподдержки все норм и относительно легко решается... ну несколько лишних телодвижений в первый раз. Для простых пользователей все очень и очень тяжело. При этом проблем с миграцией с InterBase на Firebird 2.5 (и между разными версиями FireBird) никогда не возникало. Не, я понимаю, что прогресс... но если уровень пользователей, которые будут эксплуатировать СУБД невысокий, то тут только техподдержка. А всего пару лет назад все работало и это было плюсом Firebird.
> Получается, что бекап базы нужно делать ДО того как ставится 3-я версия.Я тебе один умный вещь скажу, только ты не обижайся, бекапы всегда надо делать ДО начала работ.
> А запуск FB v3 в режиме приложения официально поломан.уп-с... а нам-то тут заливают про великое конкурентное преимущество...
Еще один "доку нечитатель". Все сгорели карусели... (с)
Firebird масштабируется от встраиваемой до сетевой без смены базы.
(Внезапно) postgresql (и даже mysql) — тоже. А вот oracle и mssql — нет.
* sqlite, clickhouse и всякие монги — нишевые решения и непонятно зачем их в треде про СУБД приплели.
на это можно mediawiki прикрутить? реально интересно.
Пока нет, нужен Маша, Мускуль, PG или SQLite. Это итак закрывает все мыслимые сценарии.Например в офисе на 250 АРМ - я разворачивал корпоративную MW на MySQL, а затем, после конфликта с админом, перенес все на SQLite. Стало работать даже быстрее. Очень редко, раза 4 в день возникали жалобы на блокировки при одновременной записи. Активных пользователей системы было около 20.
> Стало работать даже быстрее. Очень редко, раза 4 в день возникали
> жалобы на блокировки при одновременной записи.честно говоря, мне бы хватило и одной жалобы подобного рода в день, чтобы озадачиться переделыванием, на сей раз - руками.
и да, вполне можно все оставить и на sqlite, поскольку дело, скорее всего, не в бобине (в нормальном случае в нормально написанном приложении будет просто задержка, а не "перенаберите-ка эту форму из стапиццот полей заново, а то я ее что-та записать ниалле")
Жалобы были на отклик/задержку, а "перенаберите..." - действительно, можно получить только специально проявленной тупостью.Вообще если говорить о быстродействии SQLite в небольших группах (отдел 5-10 чел с 3-5 активными читателями и 1-2 писателями в минуту) - она быстрее всех прочих СУБД и вообще всех других способов обработки данных. Речь идет о файловой БД SQLite, правда на SSD. Базы in-memory мы тоже используем, но там вообще скорость космическая, для генерации сложных и больших отчетов.
> Жалобы были на отклик/задержкуа, ну так надо развлекать их чем-нибудь, понятно - прогресс-индикатор какой рисовать, не связанный с реальностью.
> Вообще если говорить о быстродействии SQLite в небольших группах (отдел 5-10 чел
> с 3-5 активными читателями и 1-2 писателями в минуту) - она
> быстрее всех прочих СУБД и вообще всех других способов обработки данных.еще бы - ты ж нагрузку растаскиваешь по их машинам, не диском же единым ;-)
то есть может и не во всех случаях, и зависит от мощности сервера и сложности структуры (а так же бестолковости конструкции хранилки в других базах), но шансы на победу у sqlite на всего лишь десятке эпизодических юзеров всегда неплохие.
А дальше один фиг переделывать.
Мне FB нравится за своё скромное потребление памяти и не раздутые возможности, что улучшает надёжность.
Вначале она ставит в тупик, как сделать новую базу с нужными правами на директории и файл, как создать админа и пользователей(нет удобного сервиса). Но потом всё идёт гладко... Функционала мне хватает на все случаи жизни.
Меня удивляет то как люди не зная firebird начинают с р а ч разводить (видимо это комплексы).
Использовал в своих проектах FB. Впечатления положительные особенно от FB2.5. А вот от mysql наоборот. MsSql жудко прожорлив и цена не адекват (express не подходил по ограничениям). postgres впечатления двоякие оставил. sqlite - это довольно узкая ниша, но со своими задачами справляется. Всё сугубо моё субъективное мнение из моего же опыта...