Спустя полтора года с момента формирования альфа-выпуска и почти после десяти лет с момента начала разработки доступна (http://www.firebirdsql.org/en/news/firebird-3-0-beta-1-relea.../) для тестирования бета-версия СУБД Firebird 3.0 (http://www.firebirdsql.org/en/firebird-3-0-0-beta1/). Изначально релиз Firebird 3.0 планировалось выпустить ещё в 2007 году, но из-за нехватки ресурсов разработка затянулась.Из особенностей (http://web.firebirdsql.org/download/prerelease/rlsnotes/Fire...) Firebird 3.0 можно выделить:
- Кодовая база переписана на языке C++ и отличается переработанной архитектурой, оптимизированной для использования на многоядерных системах;
- Новый объектно-ориентированный C++ API для разработки дополнений;
- Новая гибкая система конфигурирования;- Дополнительные модели аутентификации;
- Поддержка агрегирования прав доступа;
- Внешние хранимые процедуры, триггеры и функции (на Java, C++ и других языках);
- Поддержка задания схем шифрования данных;
- Возможность определения пользовательских PSQL-функций и DDL-триггеров;
- Средства для подключения расширений для мониторинга;
- Возможность задания триггеров, срабатывающих при удалении или изменении данных;
- Реализация полноценного логического типа BOOLEAN;
- Возможность задания таймаута, ограничивающего время выполнения запроса.
URL: http://www.firebirdsql.org/en/news/firebird-3-0-beta-1-relea.../
Новость: http://www.opennet.me/opennews/art.shtml?num=41166
Не прошло и года. А хотя нет. Прошло.
Это был очень високосный год...
Но таки рад.
Отлично.
Пусть будет. ХОРОШАЯ СУБД!
А расскажите чем именно она хорошая? Так, для общего развития интересно в каких случаях может быть оправдано выбрать из всех вариантов именно её. Чем она сильна, какие особенности?
К чему эти вопросы ни о чем? Если ты программист - просто попробуй и делай свой выбор.
Не у всех столько ненужного времени, как у вас.
Нет времени писать программы? Нет времени изучать что-то новое? Есть время писать бессмысленные комменты? Да, у меня времени полно, и сюда ерунду писать, и полезное что-то делать, почему у тебя не хватает - понятия не имею.
Я объясню: потому что ты врёшь, а он - серьёзно.
Именно. Множество дерьмовых проектов, нагло навязанных пользователям, которые поэтому вынуждены с ней трахаться, используют именно эту СУБДэшку.
> Именно. Множество дерьмовых проектов, нагло навязанных пользователям, которые поэтому
> вынуждены с ней трахаться, используют именно эту СУБДэшку.А уж сколько дерьмовых проектов на других СУБД сделано. И с ними тоже приходится это делать. Тут скорее дело в руках.
Самая беспроблемная СУБД (в отличие от всяких разных My...).
Какое же оно новое?
> Нет времени писать программы? Нет времени изучать что-то новое?Прикинь, студент, не все готовы программировать под БД, совершенно не выяснив её сильные и слабые стороны. А если ты так поступаешь, значит времени свободного девать некуда.
Прикинь, сынок, берешь и пробуешь. Я хз, как ты вообще начал программировать под что-то, ты ведь не мог знать сильных и слабых сторон своей первой СУБД, ни разу ее в глаза до этого не видев.
> Прикинь, сынок, берешь и пробуешь. Я хз, как ты вообще начал программировать
> под что-то, ты ведь не мог знать сильных и слабых сторон
> своей первой СУБД, ни разу ее в глаза до этого не
> видев.Вас прёт, всех шестерых ;)
В своё время она спокойно тянула несколько большие объемы, чем мускул - это чтобы примерно представлять уровень. Это версионник - что минимизирует проблемы с локами в обмен на мороку с вакуумом. Сейчас из вкусного у неё, пожалуй, в основном то, что она умеет работать как встроенная БД и как полноценный клиент к серверу - причем это делается одним и тем же кодом, различается лишь строка подключения.А так - просто прилично написанная БД, с меньшим количеством возможностей (и заморочек), чем мускул, но в целом примерно на его уровне.
В своё время она запомнилась не восстанавливаемыми бэкапами :)
А так - бесплатный InterBase и всё :)Кстати аффтар новости - школяр, на C++ это переписали в 2004 году, версия 1.5
В 3.0 сожно сторпроки на С++ писать, но это слишком крутой инглишЩъ для TC-а :)
А так же работающими триггерами без Trigger mutation ( привет и ораклу )
> А так же работающими триггерами без Trigger mutation ( привет и ораклу
> )мутирующие таблицы, а не триггер (код триггера же не меняется в процессе выполнения :) )
M1-Abrams использует Firebird. Но ее надо так часто перетряхивать. постоянно запарывалось содержимое blob полей. IBExpert очень удобен. сказка. в остальном был не в восторге.
Для меня FB был прекрасным учебником:
компактный, быстрый, с полным стандартным SQL, удобным инструментарием (IBExpert).Уровни изоляции транзакций (кроме грязного чтения)
Встроенная работа с массивами (расскажите, кто использовал )))
Логичная встроенная система триггеров и хранимых процедур (!!!)Просьба рассказать о решаемых задачах того, кому не хватало производительности FB!
> Для меня FB был прекрасным учебником:
> компактный, быстрый, с полным стандартным SQL, удобным инструментарием (IBExpert).
> Уровни изоляции транзакций (кроме грязного чтения)
> Встроенная работа с массивами (расскажите, кто использовал )))
> Логичная встроенная система триггеров и хранимых процедур (!!!)
> Просьба рассказать о решаемых задачах того, кому не хватало производительности FB!Ну реально не хватало, но дело не столько в производительности, а в относительной простоте PSQL ( расчёт предложения на склад сервером) хотя после 2.5 и некоторых оптимизаций стали укладываться в 4-8 минут вроде, не помню точно. Вообще в 2.5 был большой шаг вперёд.
p.s. Правда я тут узнал что в некоторых других направлениях на схожую задачу пару часов считается нормальным временем ;)
а вот чего реально не хватало, это разделение мест хранения объектов ( tablespace-ов ) т.к. было бы очень удобно выделить схему для блобов разных и для "устаревших данных" с другим местом хранения
> относительной простоте PSQLДля решения узкой, частной задачи простота - это все!!!
> 2.5 и некоторых оптимизаций стали укладываться в 4-8 минут вроде, не
использование индексов в сложном запросе с объединением таблиц на FB1.0 позволило ускориться, если память не изменяет, в 5-20 раз!
___Примечание___: Индексы так ускоряют работу с ЛЮБОЙ базой данных.> p.s. Правда я тут узнал что в некоторых других направлениях на схожую
> задачу пару часов считается нормальным временем ;)да, уж, автоматизации маловато, почти все в рукопашную... :( , зато с IBExpert все легче!
> а вот чего реально не хватало, это разделение мест хранения объектов (
> tablespace-ов ) т.к. было бы очень удобно выделить схему для блобов
> разных и для "устаревших данных" с другим местом храненияда, способ и место хранения BLOBов раньше в FB никак не отличалось от хранения таблиц с "обычными" числовыми и строковыми данными. Согласен, это не удобно :(
>> относительной простоте PSQL
> Для решения узкой, частной задачи простота - это все!!!
>> 2.5 и некоторых оптимизаций стали укладываться в 4-8 минут вроде, не
> использование индексов в сложном запросе с объединением таблиц на FB1.0 позволило ускориться,
> если память не изменяет, в 5-20 раз!
> ___Примечание___: Индексы так ускоряют работу с ЛЮБОЙ базой данных.А с чего вы взяли что их не использовали, ускорение было уже от сильно оптимизированной системы, в общем за счёт временных таблиц
> Для меня FB был прекрасным учебником:
> компактный, быстрый, с полным стандартным SQL, удобным инструментарием (IBExpert).
> Уровни изоляции транзакций (кроме грязного чтения)
> Встроенная работа с массивами (расскажите, кто использовал )))
> Логичная встроенная система триггеров и хранимых процедур (!!!)
> Просьба рассказать о решаемых задачах того, кому не хватало производительности FB!Это не ты угребища для российских ФОМСов лабал?
о чем речь?
> Это не ты угребища для российских ФОМСов лабал?Какие российские ФОМСЫ используют решения на FB?
У нее выпилили фичу невосстановимый бэкап? Или сохранили для обратной совместимости??? :)
Бэкапил... Восстанавливал... ЧЯДНТ?
> Бэкапил... Восстанавливал... ЧЯДНТ?Врешь неумело :)
Не, ври, что он врет, это ты врешь - в каждом комменте.
> У нее выпилили фичу невосстановимый бэкап? Или сохранили для обратной совместимости???
> :)с разморозкой
Почитал новости в том числе старых релизов. Не нашел пруфа удаления фичи невосстановимого бэкапа.Собственно вопрос к знатокам - починили или все еще возможно получить две записи с одним PK и аналогичные "бонусы"?
PS использую MS SQL, Oracle, PostgreSQL.
> Почитал новости в том числе старых релизов. Не нашел пруфа удаления фичи
> невосстановимого бэкапа.
> Собственно вопрос к знатокам - починили или все еще возможно получить две
> записи с одним PK и аналогичные "бонусы"?
> PS использую MS SQL, Oracle, PostgreSQL.работаю с FB > 7 лет ни разу не удалось.
> Почитал новости в том числе старых релизов. Не нашел пруфа удаления фичи
> невосстановимого бэкапа.Не было такой фичи. Бекап всегда можно было восстановить хоть и без индексов и ограничений. Просто надо внимательно про ключи читать. К тому же есть nbackup который всегда восстановим.
> Собственно вопрос к знатокам - починили или все еще возможно получить две
> записи с одним PK и аналогичные "бонусы"?Ни разу не видел такого.
Причины появления так называемых "невостановимых" бекапов (gbak) описаны ниже и они исправлены.
>> Почитал новости в том числе старых релизов. Не нашел пруфа удаления фичи
>> невосстановимого бэкапа.
> Не было такой фичи. Бекап всегда можно было восстановить хоть и без
> индексов и ограничений. Просто надо внимательно про ключи читать. К тому
> же есть nbackup который всегда восстановим.Он уже не в первой новости отличается :)
При этом я так и непонял, починили ли фичу в PG, когда пол каталога с базой удаляешь? ;)
Если вам не нужны репликации, кластеризация, возможность восстановления из родных бакапов, то это ваш выбор.
> Если вам не нужны репликации, кластеризация, возможность восстановления из родных бакапов,
> то это ваш выбор.Просто делает ненужным embedded (personal) MS SQL...
Чем sqlite не угодил?
Да не субд, но для embedded и не нужен именно субд.
Не то чтобы не угодил... Но если вдруг база становится тяжеловата для sqlite - придётся возиться с миграцией. А с Firebird - поднимаем сервер, меняем строку подключения - и всё в порядке.
>>Да не субд, но для embedded и не нужен именно субд.Вернул сюда эту строчку.
> Не то чтобы не угодил... Но если вдруг база становится тяжеловата для sqlite - придётся возиться с миграцией.???
>А с Firebird - поднимаем сервер, меняем строку подключения - и всё в порядке.?!?!?!?!
Приговор: тыщща лет расстрела! И ремнём по причинным местам!
PS: Впрочем ты наверное не смог перевести слово "embedded" и где его применяют? :)
> PS: Впрочем ты наверное не смог перевести слово "embedded" и где его
> применяют? :)в небольших приложениях к примеру, когда потом вдруг этим приложением захочет одновременно пользоваться 10 человек.
по сути драйвер FB embedded может работать с внешним сервером. Поэтому реально меняется только строчка подключения, что бы вы себе не мнили про значение этого слова ;)
> Если вам не нужны репликации, кластеризация, возможность восстановления из родных бакапов,
> то это ваш выбор.да задолбали уже про возможность невосстановления, у людей годами в производстве работает, есть не простит, и хранит куда более важные данные чем странички лицлкниг всяких.
>> Если вам не нужны репликации, кластеризация, возможность восстановления из родных бакапов,
>> то это ваш выбор.
> да задолбали уже про возможность невосстановления, у людей годами в производстве работает,
> есть не простит, и хранит куда более важные данные чем странички
> лицлкниг всяких.p.s. Да кстати восстановление и бэкапирование Oracle та ещё задачка, не говоря уже о том что родной инструмент для создания копий "на лету" на лету их создать не может т.к. sequence-ы слетают...
Просто многие мануал по gbak/nbackup читают через строчку и "по понятиям", а потом кричат на форумах, что у них всё поломалось.
Анонимы такие анонимы. Конкретные вопросы задали: чем лучше аналогов? когда стоит использовать?
Ты ж не думаешь, что тебе прямо так честно и ответят: ещё одна ничем не примечательная субд...Когда-то давно firebird был заменой для interbase, что несколько упрощало разработку на delphi. но то было лет десять назад...
> Анонимы такие анонимы. Конкретные вопросы задали: чем лучше аналогов? когда стоит использовать?в складских/управленческих решениях, когда не очень нужна репликация, есть потребность не только в чтении но и записи данных, а так же есть понимание что такое транзакции и зачем они нужны. Так же когда нужно базу в один файл положить
Спасибо
А тем временем 1.5.х ветку несколько лет как выпилили из всех линуксячьих репов, в то время как половина продакшена, юзающего firebird сидит именно на ней, и даже на 2.1.х не чешется переходить. Так победим, да.:(
> А тем временем 1.5.х ветку несколько лет как выпилили из всех линуксячьих
> репов, в то время как половина продакшена, юзающего firebird сидит именно
> на ней, и даже на 2.1.х не чешется переходить. Так победим,
> да.:(работает не трогай вам незнакомо ?
firebird это взрослая, надежная бд для продакшн(версии 2.1 отчасти 2.5).
В firebird отличная поддержка транзакций, оракло подобный psql.
Высокая отказоустойчивость при ресетах питания.
Реально параллельная работа в классик режиме.
Минусы: не самая быстрая, нет репликаций из коробки, утилиты управления не очень логичны.
В России очень популярна для ведомственных бд и всякого софта коммерческого.
У нас в продакш более 400 клиентов на ней лет 10 пользуются.
Если нужна надежность, параллельность и транзакционная целостность - то firebird это отличный выбор.
Ну, популярна она в России в основном потому, что дельфями, на которых этот самый софт писался, хорошо поддерживалась еще со времён бытия Interbase. Впрочем, не могу сказать, что это плохо - многие вещи я бы и сейчас именно на дельфях писал при выборе - там, где нужен более-менее прямой фронтэнд к базе с удобным гуем они очень хороши были.А вот PSQL у него и правда хороший, без мускуловских глупостей и вольностей.
>Ну, популярна она в России в основном потому, что дельфями, на которых этот самый софт писалсяВ основном да.
Но когда винда гнется - переносят на Linux и отлично работает.
Частично такие проги уже переписаны на веб клиенты тк делфи не в моде ))И все же по транзакциям и psql она на голову выше мускуля да и по надежности тоже.
С посгрискл сравнивать сложно тк в нем много новых фич и понятно проблемок.
firebird меняется редко и поэтому более предсказуем и менее фичист.
Пардон, как у этой взрослой СУБД с горизонтальной масштабируемостью и кластеризацией?
> Пардон, как у этой взрослой СУБД с горизонтальной масштабируемостью и кластеризацией?нормально, т.е. она не заточена на задачи в которых это нужно :)
проблема в том что у тех кто заточен проблемы с ACID и прочие фишки вылазят.
у FB своя ниша - односервеные и безсервеные решения, есть люди ( фармостандарт ) которые делают и репликации и прочее, но это уже "доработки"После выхода 3.0 возможно будут созданы "нормальные" системы репликации, благодаря новому API, так же ИМХО будет рост использования, т.к. появится возможность шифрования ( некоторым нужно было позарез )
Помимо прочего большинство разработчиков Русские, ввиду политической ситуации может оказаться что выбор в некоторых организациях будет за FB.Вообще кому интересно, много о FB есть на SQL.ru ( так сказать форум техподдержки фактически, если грамотные вопросы задавать )
> Вообще кому интересноДа никому это неинтересно при наличии PostgreSQL (Postgres-XC и Postgres-XL)
>> Вообще кому интересно
> Да никому это неинтересно при наличии PostgreSQL (Postgres-XC и Postgres-XL)угу тут как раз на днях создавал новую БД PG
> 40,9 МБ
> 1000 файловкак там в мультике
"Если близко воробей - Мы готовим пушку"
> как там в мультике
> "Если близко воробей - Мы готовим пушку"...байка (пруфлинк искать не хочу)
Когда появились винты на 1Tb энтузиасты FB решили проверить, потянет или нет зверушка?
Генератором заливали базу неделю! ... в результате оказалась что все работает, производительность осталась примерно на том же уровне... однако, тоже масштабируемость...
> Вообще кому интересно, много о FB есть на SQL.ru ( так сказатьibase.ru Дмитрий Кузьменко рулит!
> У нас в продакш более 400 клиентов на ней лет 10 пользуются.Всё так - ничего нового на нём нет :) Что успели дельфисты наклепать, вот и всё ...
> Если нужна надежность, параллельность и транзакционная целостность - то firebird это отличный выбор.Пергаааааа! Кто из ныне живущих этого не умеет? +полнетекстовый поиск, + ркпликации\кластеры +OO-store +стотыщь плюшек которые появились в мире DB за последние 10 лет.
А этот птниц вам нужет _только_ если нужно че-то давать древнему дельфисофту :) Всё.
Да и то - давать придётся старьё, 1.5\2.* Не факт что на тройке чего не вылезет :-\
>древнему дельфисофтуОткрою тебе, о мой юный неграмотный друг, страшный-престрашный секрет: новый софт, юзающий 1.5.х, пишут до сих пор. Бо в этих ваших интерпрайзах никто не будет ломать всю инфраструктуру ради замены старых цифирок на новые.
>>древнему дельфисофту
> Открою тебе, о мой юный неграмотный друг, страшный-престрашный секрет: новый софт, юзающий
> 1.5.х, пишут до сих пор. Бо в этих ваших интерпрайзах никто
> не будет ломать всю инфраструктуру ради замены старых цифирок на новые.Самое интересное что когда мы переходили с 2.0 на 2.5.хх основная проблема была в UDF, а так по базе все процедуры неплохо тработаны ( да там планы ненужные порезать пришлось ) так что если нет udf то ИМХО смысла сейчас разрабатывать на 1.5 нет, но тут вопрос скорее в нежелании чем в расходах.
А так, на мой взгляд, 2.5 позволяет серьёзно сократить скорость разработки.
>> У нас в продакш более 400 клиентов на ней лет 10 пользуются.
> Всё так - ничего нового на нём нет :) Что успели дельфисты
> наклепать, вот и всё ...
>> Если нужна надежность, параллельность и транзакционная целостность - то firebird это отличный выбор.
> Пергаааааа! Кто из ныне живущих этого не умеет?вы будете удивлены но с транзакциями проблему почти у всех ( если с FB сравнивать ) пример вам от Oracle:
insert into table1 ( a, b) values ( 1, 2);
alter table1 add ( c );
rollback;
select * from table1 ->
1,2
>[оверквотинг удален]
>> наклепать, вот и всё ...
>>> Если нужна надежность, параллельность и транзакционная целостность - то firebird это отличный выбор.
>> Пергаааааа! Кто из ныне живущих этого не умеет?
> вы будете удивлены но с транзакциями проблему почти у всех ( если
> с FB сравнивать ) пример вам от Oracle:
> insert into table1 ( a, b) values ( 1, 2);
> alter table1 add ( c );
> rollback;
> select * from table1 ->
> 1,2про MySQL лучше вообще не вспоминать :)
да ещё у меня Oracle в сложных VIEW пустое множество возвращал при наличии реальных данных ( 11.2 )
> вы будете удивлены но с транзакциями проблему почти у всех ( если
> с FB сравнивать ) пример вам от Oracle:
> insert into table1 ( a, b) values ( 1, 2);
> alter table1 add ( c );
> rollback;
> select * from table1 ->
> 1,2А где здесь проблема с транзакциями? Походу месье не знает, что Oracle делает implicit commit на каждый DDL.
Покажите проблему с транзакциями на DML.
>> вы будете удивлены но с транзакциями проблему почти у всех ( если
>> с FB сравнивать ) пример вам от Oracle:
>> insert into table1 ( a, b) values ( 1, 2);
>> alter table1 add ( c );
>> rollback;
>> select * from table1 ->
>> 1,2
> А где здесь проблема с транзакциями? Походу месье не знает, что Oracle
> делает implicit commit на каждый DDL.
> Покажите проблему с транзакциями на DML.это не бага это фича... однако она создаёт некоторые неудобства и даже проблемы.
p.s. По сути любое поведение можно описать в доках и говорить что это не проблема.
> это не бага это фича... однако она создаёт некоторые неудобства и даже проблемы.вы делаете DDL в том же потоке исполнения, что и DML?
какая задача этого требует? есть ли альтернативные решения?> p.s. По сути любое поведение можно описать в доках и говорить что это не проблема.
Есть фичи, которые мешают при обычных ситуациях. Есть фичи, которые срабатывают в необычных.
DDL выполняется (обычно), когда выполняется обновление приложения. Или как минимум из специально выделенного потока/соединения. Проводить корректировку ОДНОВРЕМЕННО с манипуляцией данными из того же потока исполнения очень спорная задача. Прямо таки хочется знать, что ее вызывает. =)
PS проверил на PG - DDL не вызывают авто-коммита. Буду знать :)<trollmode>
PPS идея бэкапа в том, что его можно восстановить (что логично). Соответственно, завершив процедуру бэкапа без ошибок ожидается, что, на той же версии СУБД, восстановление будет выполнено без ручных корректировок.
</trollmode>
>[оверквотинг удален]
> вы делаете DDL в том же потоке исполнения, что и DML?
> какая задача этого требует? есть ли альтернативные решения?
>> p.s. По сути любое поведение можно описать в доках и говорить что это не проблема.
> Есть фичи, которые мешают при обычных ситуациях. Есть фичи, которые срабатывают в
> необычных.
> DDL выполняется (обычно), когда выполняется обновление приложения. Или как минимум из специально
> выделенного потока/соединения. Проводить корректировку ОДНОВРЕМЕННО с манипуляцией
> данными из того же потока исполнения очень спорная задача. Прямо таки
> хочется знать, что ее вызывает. =)
> PS проверил на PG - DDL не вызывают авто-коммита. Буду знать :)Обычно это у вас, начинали бы с FB ваша реакция на оракл была бы возможно другой.
> <trollmode>
> PPS идея бэкапа в том, что его можно восстановить (что логично). Соответственно,
> завершив процедуру бэкапа без ошибок ожидается, что, на той же версии
> СУБД, восстановление будет выполнено без ручных корректировок.
> </trollmode>Продолжим?
Если поменять системные таблицы, то база будет нормально бэкапиться? ( невосстановимый бэкап ( да ито это не совсем правда ) получается только если сделать что-то не правильное, стандартный вариант alter table add ( a not null ), и это вроде как поправили, просто благодаря транзакционности FB это действие шло одновременно с update у тех кто понимал что делает )Или скажем так про ещё одну фичу - если pl/sql пакет не скомпилировался то зачем заменять рабочий на невалидный ;)
> <trollmode>
> PPS идея бэкапа в том, что его можно восстановить (что логично). Соответственно,
> завершив процедуру бэкапа без ошибок ожидается, что, на той же версии
> СУБД, восстановление будет выполнено без ручных корректировок.
> </trollmode>Не удачная попытка. Утилита gbak похожа на экспорт в скрипт. Соответственно если в этом метаданных есть косяк, то он не может быть выполнен. Вон в Оракле от этого всякие инвалиды появляются. А в PG ты вообще не узнаешь, что твоя функция кривая пока не запустишь её. Так что и в них корректировки потребуются. В режиме игнорирования ошибок gbak'ом можно конечно восстановить и кривой бекап, но только без кривых объектов.
nbackup это страничный бекап. Соответственно копию можно снять всегда, как и восстановить её. И существует она с версии 2.0, т.е. 2006 года.
> проверил на PG - DDL не вызывают авто-коммита. Буду знать :)Да, в PG это вообще адова фича - транзакционный DDL
Только что попробовал твой пример (запрос из SQL Developer, база Oracle Database 11g Release 11.2.0.3.0 - 64bit Production) - ничего не вернул запрос, так что...
> Только что попробовал твой пример (запрос из SQL Developer, база Oracle Database
> 11g Release 11.2.0.3.0 - 64bit Production) - ничего не вернул запрос,
> так что...http://nv81.ru/gdglshgl/ttt111.png
Причём это поведение официально прописанное в доках.
> Только что попробовал твой пример (запрос из SQL Developer, база Oracle Database
> 11g Release 11.2.0.3.0 - 64bit Production) - ничего не вернул запрос,
> так что...********************
SQLDeveloper ( Oracle )
table TTT111 created.
1 rows inserted.
table TTT111 altered.
rollback complete.
A B C
---------- ---------- ----------
1 2table TTT111 dropped.
*******************
версия 11.2.0.3.0
А еще в Дельфях есть нативный драйвер к этой базе, поэтому для школьников - лучший выбор
>нативный драйвер
>лучший выборТы сам-то пробовал?:)
Сынок, с FireDAC доступ к любой БД из Delphi - одинаков для программиста, так что это не аргумент.
> Сынок, с FireDAC доступ к любой БД из Delphi - одинаков для
> программиста, так что это не аргумент.охренеть технологии! ок, lmdb нормально работает?
Что такое lmdb, яндекс упорно исправляет поисковый запрос на imdb. Это СУБД? Видимо, не настолько востребована, чтобы делать ее поддержку, т.к., действительно, нет ссылки на драйвер для такой фигни в компонентах из FireDAC Links... Так я тоже могу вспомнить какую-нибудь СУБД местного пошиба, поддержки которой нет в FireDAC. Не надо все понимать буквально, вместо "к любой" читай "к любой, которая достаточно распространена".
ну что я могу сказать — профессионала видно сразу.
> ну что я могу сказать — профессионала видно сразу.шутки ради:
...of a pure in-memory...and is only limited to the size of the virtual address space, (it is not limited to the size of physical RAM).Со всех сторон обложили. Вроде pure а вроде нет :)
да вообще издеваются. ещё и от яндекса прячутся, никак не найти вообще.
> да вообще издеваются. ещё и от яндекса прячутся, никак не найти вообще.угу и гитхаб тоже спрятался :) ( по версии МТС на текущий момент )
> ну что я могу сказать — профессионала видно сразу.Я могу сказать, что если даже поисковик (что Яндекс, что Гугл) не знает, что это такое - откуда мне знать? :) по запросу firebird вываливается в яндексе 4 млн ссылок, по lmdb - 24 тысячи, как бы разница на 2 порядка... Т.к. на странице этого "проекта" сравнивается, как я понял, с NoSQL СУБД, имен которых я тоже не знаю - видимо, это какой-то совсем узкоспециализированный продукт :) Какое тогда он отношение имеет к СУРБД и firebird в частности?
>> ну что я могу сказать — профессионала видно сразу.
> Я могу сказать, что если даже поисковик (что Яндекс, что Гугл) не
> знает, что это такое - откуда мне знать? :) по
> запросу firebird вываливается в яндексе 4 млн ссылок, по lmdb -
> 24 тысячи, как бы разница на 2 порядка... Т.к. на странице
> этого "проекта" сравнивается, как я понял, с NoSQL СУБД, имен которых
> я тоже не знаю - видимо, это какой-то совсем узкоспециализированный продукт
> :) Какое тогда он отношение имеет к СУРБД и firebird в
> частности?он про способ поиска вероятно :) не стоит разводить дискуссию об этом, Арису может таких гадостей понаписать, что ветку "поудаляют" :)
> Какое тогда он отношение имеет к СУРБД и firebird в частности?а такое, что это БД. в #84 я читаю: «к любой БД». можем взять lmdb. а можем взять вообще файловую систему, которая тоже БД, почти всегда ещё и иерархическая. раз.
«реляционность» без проблем реализуется на любой БД. два. помимо этого, ни в #84, ни в #98 «Р» не было. зато волшебным образом появилось в #104. заодно сделали вид, что разговор вообще не от #84 отделился, так что говорим только про firebird.
то, что ты не знаешь ничего, что не находится в яндексе по одному запросу и в первых строчках — это хороший показатель твоего профессионализма. вместе вот с этим: «NoSQL СУБД, имен которых я тоже не знаю».
в общем, ты зачем-то вписался за #84, и в итоге буквально двумя постами смог опозорить не только себя, но и то ПТУ, в котором учился. ex ungue leonem.
Чушь какую-то пишешь, при чем тут файловая система? Реляционные БД - в которых есть сущности (Entity), которые традиционно представляют в виде таблиц, и между этими сущностями существуют связи (Relationship) по первичным/внешним ключам. А твоя lmdb - просто хранилище вида ключ-значение. Для организации хранения данных в таком виде я могу и просто кучку ini или xml файлов использовать, без этой фигни с громким названием "СУБД". ПТУ, который я оканчивал когда-то, входит в 50 лучших ВУЗов СНГ.
> ПТУ, который я оканчивал когда-то, входит в 50 лучших ВУЗов СНГ.действительно, совсем беда с образованием.
Я не знаю, что оканчивал автор вышеприведенного комментария, пусть даже МГТУ им. Баумана, только в теме, где обсуждают достоинства и недостатки реляционных СУБД и SQL, вплетать какую-то непонятную систему хранения данных, которой пользуются 2.5 калеки - ну какой в этом смысл, выпендрится, что слышал о такой системе и попытаться поставить собеседников в недоумение, потому что они не слышали? :) Кто-то молчит, кто-то вон отписывается, а его еще и дураком называют :)
о, ещё один. тоже читать не умеет, зато кидается защищать собратьев по разуму. и у тебя ПТУ в какие-то лучшие входит?
> Что такое lmdb, яндекс упорно исправляет поисковый запрос на imdb. Это СУБД?
> Видимо, не настолько востребована, чтобы делать ее поддержку, т.к., действительно, нет
> ссылки на драйвер для такой фигни в компонентах из FireDAC Links...
> Так я тоже могу вспомнить какую-нибудь СУБД местного пошиба, поддержки которой
> нет в FireDAC. Не надо все понимать буквально, вместо "к любой"
> читай "к любой, которая достаточно распространена".
Посмотрел исходники транка... какое-то тупое переписывание с сишки.
> Кодовая база переписана на языке C++молодцы, чо. пора на js переписывать, теперь js модный.
>> Кодовая база переписана на языке C++
> молодцы, чо. пора на js переписывать, теперь js модный.нет людей готовых код на си поддерживать.
> нет людей готовых код на си поддерживать.а на цпп и поддерживать не надо, всё равно фигня.
>> нет людей готовых код на си поддерживать.
> а на цпп и поддерживать не надо, всё равно фигня.не успели им D предложить ;)
>Пардон, как у этой взрослой СУБД с горизонтальной масштабируемостью и кластеризацией?Горизонтально в пределах одного сервера по процам - просто супер в классик режиме.
Если кластер, то из коробки увы нет.
Мы делали тестовый мастер-мастер в 2.1 на ocfs немного допилив систему блокировок. Работало немного медленнее, хотя в целом приемлемо.
Но тк хватает и просто HA кластера, то развивать тему пока не стали.
HA можно и через встроенный шадоу или через тот же сетевой блочный девайс.Скажем так это взрослая БД немного отставшая в развитии, но все таки это промышленная БД и на ней не страшно пускать продкшен с учетом бабла и прочее.
Понятно, что для веба я бы взял мускул там не критично.
>[оверквотинг удален]
> Мы делали тестовый мастер-мастер в 2.1 на ocfs немного допилив систему блокировок.
> Работало немного медленнее, хотя в целом приемлемо.
> Но тк хватает и просто HA кластера, то развивать тему пока не
> стали.
> HA можно и через встроенный шадоу или через тот же сетевой блочный
> девайс.
> Скажем так это взрослая БД немного отставшая в развитии, но все таки
> это промышленная БД и на ней не страшно пускать продкшен с
> учетом бабла и прочее.
> Понятно, что для веба я бы взял мускул там не критично.В пределах одного сервера, super-classic 2.5 работает отлично, проверено за несколко лет, по сравнению с 2.0 classic только плюсы.
Автор накосячил в описании. Взял то чего там реально нет, но обещали года 1.5 назад. А некоторые фичи там уж как 10 лет есть.> - Поддержка агрегирования прав доступа;
нет там этого, первоначально планировалось, но так как по срокам не успевали отложили
> - Поддержка задания схем шифрования данных;
не схем шифрования, а возможность написания плагинов шифрования
> - Средства для подключения расширений для мониторинга;
нету такого, есть возможность заменить стандартный плагин трассировки, но не мониторинга
> - Возможность задания триггеров, срабатывающих при удалении или изменении данных;
это с рождения было
> - Возможность задания таймаута, ограничивающего время выполнения запроса.
это тоже отложили
Автор не написал:
- identity
- ссылка на курсор как на переменную типа запись
- смена роли на лету
- отображение объектов безопасности ОС на объекты безопасности FB
- шифрование трафика
- пакеты, аля Оракл (возможностей конечно сильно меньше)
- подфункции и подпроцедуры
- изменения NULL/NOT NULL для столбцов и доменов и ALTER TABLE T ADD F INT NOT NULL, если есть данные не пройдёт, надо DEFAULT указать (это одна из причин, т.н. "невосстановимого бекапа")
- запрет модификации большинства системных таблиц (это одна из причин, т.н. "невосстановимого бекапа")
- оператор MERGE допилен для поддержки стандарта SQL:2008 (предложение DELETE, множество WHEN MATCHED/WHEN NOT MATCHED секций с дополнительными условиями)
- привилегии USAGE на генераторы и исключения
- DDL привилегии
ах да. Чтобы обломать троллинг на взлёте.Стабильность курсора тоже починили.
Т.е. всякие insert t select * from T и другие приколы тоже теперь работают нормально
Нет промышленного софта? Кому в глаз?!
Начиная с 1.0 работаем с Firebird.
Продаём свою систему АСУ уровня предприятия.
25 регионов РФ, более 200 инсталляций, не счесть удалённых АРМ. Конечноых пользователей - тысяч несколько, не считали.Безглючная легко встраиваемая СУБД ПРАКТИЧЕСКИ НЕ ТРЕБУЮЩАЯ АДМИНИСТРИРОВАНИЯ!
Практически - это значит, что есть громадная наработанная статистика, и есть системы, работающие без участия DBA годами!Мифы про невосстановимые бэкапы на ровном месте - не слышал, но при неисправном оборудовании умейте с ними обращаться. Мы своих клиентов не бросаем - помогаем техподдержкой сами.
За 10+ лет эксплуатации этих систем всего раза два не смог поднять после сбоя базу данных и пришлось воспользоваться для восстановления данных созданным до сбоя по расписанию бэкапом.Будем теперь пробовать версию 3.0 и осваивать её новые возможности.
Спасибо разработчикам!
слушай, вы в своей версии ПО использовали апдейт, который использует измененное значение
# UPDATE T SET A = B, B = A# старый режим: A становится равным B, B не меняется
# новый режим: значение A и B меняются
до 2.5. есть поддержка двух схем апдейта (параметр OldSetClauseSemantics в конфиге) а в 3.0 его не будет.и это, к сожалению веская причина не переходить на 3.0
> слушай, вы в своей версии ПО использовали апдейт, который использует измененное значение
> # UPDATE T SET A = B, B = A
> # старый режим: A становится равным B, B не меняется
> # новый режим: значение A и B меняются
> до 2.5. есть поддержка двух схем апдейта (параметр OldSetClauseSemantics в конфиге) а
> в 3.0 его не будет.
> и это, к сожалению веская причина не переходить на 3.0Эта не причина. Не надо было полагаться на нестандартное поведение. Просто надо исправить в твоём приложении этот косяк.
Там ещё и стабильность курсора исправлена. Если у кого то возникла идея воспользоваться этим, то он ССЗБ.
> слушай, вы в своей версии ПО использовали апдейт, который использует измененное значение
> # UPDATE T SET A = B, B = AНет, и в голову даже не могло придти использовать такое.
Ну что тебе сказать, OVA ...ППЦ
Насколько легко на него мигрировать сервер с InterBase образца 2000 года?
> Насколько легко на него мигрировать сервер с InterBase образца 2000 года?довольно тяжело. В приложении и ХП надо все кривые запросы выловить.
А какой смысл? Если приложение 14 лет работало и за это время не мигрировало ни на одну из более новых версий.