Доступен (http://www.firebirdsql.org/en/news/firebird-2-5-4-sub-releas.../) корректирующий релиз реляционной СУБД Firebird 2.5.4 (http://www.firebirdsql.org), продолжающей развитие кода БД InterBase 6.0, открытого в 2000 году компанией Borland. Firebird распространяется под свободной лицензией MPL и поддерживает стандарты ANSI SQL, в том числе такие возможности, как триггеры и хранимые процедуры.Кроме исправления ошибок, в новой версии добавлена (http://www.firebirdsql.org/file/documentation/release_notes/...) возможность (http://www.firebirdsql.org/file/documentation/release_notes/...) низкоуровневой проверки целостности дисковых структур таблиц и индексов с сохранением доступности БД для выполнения других операций (в режиме online). Реализован (http://tracker.firebirdsql.org/browse/CORE-4671) механизм раннего освобождения внутренних временных блобов, что позволило высвободить дополнительную память и дисковое пространство.
URL: http://www.firebirdsql.org/en/news/firebird-2-5-4-sub-releas.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=41952
Кто поделится опытом? Шустрее ли MySQL? Когда можно и нужно юзать, если, скажем, репликация не нужна.Спасибо ответившим.
это из разных вселенных СУБД. FB (как и сам Interbase/Growe) - полноценная, полностью SQL/ACID-совместимая реляционная БД, с полной поддержкой UDF, DDL и прочего. также реалтайм нежесткий реализован(во встраиваемых версиях(юзаются много где, вплоть до американских танков и другого) и жесткий есть).
если и сравнивать то с слоником/постгресклом или ораклом, нарное.
совсем другая весовая категория, повторюсь.
их хотели схавать обманом российские/оффшорные рейдеры софтверные, но не прокатило.
Угу. И в результате она вообще стала открытой.
(И почти никому не нужна. Судя по интенсивности развития)Зыж
Как много юзавший и интербэйз, и оракл, и мускул.
Последний быстрее (и гибче. Вопрос был об этом, а не о вашей лекции на тему). К тому же он не субд, а движок по управлению различными хранилищами данных (включая ACID, да-да).
Интербэйз (и сабж как наследник) хороши для разработки, тестов, легкого применения,.. и который стал фактически невостребованным с уменьшением популярности делфей/билдера.
Для серьёзного применения — оракл. Благо перевести с интербэйза на него наимение трудозатратно (Думаю именно так и задумывалось байдезигн).
Да, версилнник. Как и оракл. Но точно не для нагруженного применения даже близко.Ззыж
К сабжу отношусь более чем положительно. Но не надо сказок. Откровенно жалел, что оракл не захавала борланд (после открытия сабжа есесно :D)
Чуть ли не единственный случай моего сожаления из всех приобретений ораклом (которого таки не было :D).
Что привело к последующему упадку делфей, с++билдера, кайликса.. ну и сабжа за компанию.
Очень рад, что он всё-таки жив (благодаря своевременному открытию сырцов). Хоть уже и не так востребован.
Если что и хотели схавать, то средства разработки. А сабж,.. Вон он. Хавай — не хочу. Не гпл чай.
> Что привело к последующему упадку делфей, с++билдера, кайликса.. ну и сабжа за
> компанию.Ты бы хоть поставил RAD Studio из последних - реальный конкурент по удобству ей только Visual Studio мелкомягкая.
Тот ещё сорт того самого, до MS VS им не знаю как до чего топать. Ещё столько денег берут за это позорище.
Я за все время использования разных версий потратил 0 рублей 0 копеек, для меня это - вполне нормальная сумма:)
> Тот ещё сорт того самого, до MS VS им не знаю как
> до чего топать. Ещё столько денег берут за это позорище.Да им обеим до emacs'а, как до Луны!
> Для серьёзного применения — оракл. Благо перевести с интербэйза на него наимение трудозатратно (Думаю именно так и задумывалось байдезигн).Это шутка такая? У интербейза язык хранимых процедур вообще не на что другое не похож.
И что?
Переписывать клиента то нет нужды, поменял датасоурс и фактически всё.
И возможно это благодаря схожести в управлении транзакциями, блокировками и тд, а не хранимыми процедурам (да, их нужно адаптировать. А в каких субд не нужно? Похожи языки или нет, а работы столько же на стороне субд)
Короче, дело так - вопрос ваш не читал, но отвечу, догадавшись о его сути: для ембендовки лучше подойдет SQLite, а как СУБД лучше юзать PostgreSQL9.4 с кластеризацией, репликацией, JSONB и т.д. Вообщем со всем тем, чего в фаербёрде нет и в ближайшее столетие не планируется.
> Короче, дело так - вопрос ваш не читал, но отвечу, догадавшись о
> его сути: для ембендовки лучше подойдет SQLite, а как СУБД лучше
> юзать PostgreSQL9.4 с кластеризацией, репликацией, JSONB и т.д. Вообщем со всем
> тем, чего в фаербёрде нет и в ближайшее столетие не планируется.Там может тогда лучше Оракл юзать, не? Там полно всего, чего в Постгресе нет и не планируется :)
например? чего конкретно?
> лучше Оракл юзать, не?Цена лицензии, а?
увы, нет. проще перечислить то, что не лучше Оракла будет, чем наоборот.
> Кто поделится опытом? Шустрее ли MySQL? Когда можно и нужно юзать, если,
> скажем, репликация не нужна.Так MySQL умер вроде, не? Или ты MariaDB имеешь ввиду?
>Или ты MariaDB имеешь ввиду?какая ему разница, если он умеет только mysql, а остальные не умеет :)
> Так MySQL умер вроде, не? Или ты MariaDB имеешь ввиду?MariaDB - это дистрибутив Oracle MySQL с небольшими "доработками"
>Шустрее ли MySQLна чем? На простейших выборках по первичному ключу - мускулу равных нет, только nosql.
А на более менее жизненных задачах - отчеты, транзакциях (в том числе каскадные, чего в мускуле еще лет 10 не будет) - намного быстрее, плюс свобода udf. Но. Его, как и любую СУБД надо уметь готовить :)
На более-менее большом наборе данных на простейших выборках по первичному ключ Postgresql рвет MySQL как Тузик грелку. На маленьких сопоставимы.Порог с которого надо использовать NoSQL хранилища где-то от 80.000.000 - 100.000.000 записей. Но и это зависит от железа, рук ДБА и много чего еще.
> Postgresql рвет MySQL как Тузик грелкуда-да, сказочники такие сказочники, если бы оно хоть отчасти было так, я бы только на pg и сидел :)
>Порог с которого надо использовать NoSQL хранилища где-то от 80.000.000 - 100.000.000 записей
это заявление такой же тык в воздух, как и предыдущее. Ибо все строится от задач, а не от того, что кто-то там посчитает "количество записей в базе" (это что за форма подсчета такая?) и скажет "надо" :)
>Порог с которого надо использовать NoSQL хранилища где-то от 80.000.000 - 100.000.000 >записей. Но и это зависит от железа, рук ДБА и много чего еще.Я, наверное, отстал от жизни - никогда не использовал NoSQL-СУБД, только примерно знаю, что это - просто хранилища "ключ-значение". Имеет смысл для хранения всякой неструктурированной ерунды вроде мультимедиа-данных. Таким образом, как может, скажем, в биллинговой системе какого-нибудь условного Ростелекома или Сбербанка, где счет записей идет даже не на миллионы, а на миллиарды, но записи все однотипны, NoSQL-СУБД заменить традиционную реляционную?
Не совсем "ключ-значение", т.к. "key-value" только один из типов NoSQL БД. А есть еще документоориентированные, колончатые, граф-ориентированные и т.д. Под задачу хранения "неструктурированныой мультимедиа ерунды" надо всё же подбирать базу по серии критериев. Завтра Вам захочется навешивать к мультимедиа объекту неограниченный набор атрибутов и быстрый поиск по нему - а тут раз и база "не шмогла". Начните хотя бы отсюда - если у Вас стоит задача выбора http://nosql-database.org/ - беглый обзор множества популярных баз. А потом уже сравнивать между нескольких.
Ух ты, оно еще живо. Печально.
Я тебе больше скажу - я на с ее использованием приложения вполне успешно пишу(когда Оракл неоправданно использовать), т.к. требования к системным ресурсам просто смешные по нынешним временам.
Вам было бы неплохо познакомиться с какой-нибудь настоящей СУБД, скажем, постгресом.
>Вам было бы неплохо познакомиться с какой-нибудь настоящей СУБД, скажем, постгресом.Я с ораклом работаю 8 часов 5 дней в неделю :) Но файрбёрд мне нравится - ресурсов потребляет мало, IBExpert даже удобнее, чем Oracle SQL Developer, таскать на клиентские машины в довесок к своим программам 100 МБ Instant Client не нужно - красота. Так что мне не нужна "настоящая" СУБД, которая, возможно, в чем-то превосходит файрбёрд (на словах), но уступает ораклу (на деле) :)
> Вам было бы неплохо познакомиться с какой-нибудь настоящей СУБД, скажем, постгресом.для начала пусть Postgres научится валидировать хранимые процедуры. А то удалил какой-нибудь столбец таблицы, а то что 10 процедур окривели заметишь только во время их выполнения и то не факт что сразу ибо процедура может быть ветвистой.
Да пусть живёт, жалко чтоле. опенсорс.
Кстати, в каких БД есть режим строгого соблюдения стандарта SQL, чтобы непереносимые запросы сразу возвращали ошибку?
Кто тебе заставляет использовать не стандартные расширения в СУБД? Используй только то, что в ANSI прописано и будет переносимо на всех СУБД.
> Кстати, в каких БД есть режим строгого соблюдения стандарта SQL, чтобы непереносимые
> запросы сразу возвращали ошибку?sql_mode в mysql, у postgresql - наоборот есть опции для выключения ansi режима.
Этот ужас без репликации и с невосстанавливающимися бэкапами еще не сдох?
Так вроде бы клялись соседским поросёнком что бэкапы починили? Или как обычно?
Как обычно, к сожалению