Компания Oracle сформировала новую ветку СУБД MySQL 9.5.0. Сборки MySQL Community Server 9.5.0 подготовлены для всех основных дистрибутивов Linux, FreeBSD, macOS и Windows. В соответствии с внедрённой в 2023 году моделью формирования релизов, MySQL 9.5 отнесён к веткам "Innovation". Innovation-ветки рекомендованы для тех, кто хочет раньше получать доступ к новой функциональности, публикуются каждые 3 месяца и поддерживаются только до публикации следующего значительного релиза (например, после появления ветки 9.5 прекращена поддержка ветки 9.4). Зимой планируют сформировать LTS-релиз 9.6, рекомендованный для внедрений, которым необходима предсказуемость и длительное сохранение неизменного поведения. Следом за LTS-веткой будет сформирована новая Innovation-ветка - MySQL 10.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64100
Инноваций вагон
Самая главная инновация -- это бамп версии
Заброшенные базы никому не нужны.
Полинтернета на ней работает. Это заброшенная?
WWW это далеко не полинтернета. Интернет это вообще глобальная сеть на IP-протоколе: BGP, SMTP, DNS, IPSec и тд - это всё интернет. Причем тут какая-то твоя СУБД?
Вевеве - давным-давно уже ничего общего не имеет с "lamp" поделками.васян-сайтики на вротпрессе - это не пол-интернета и даже не пол-www. Это просто васян-сайтики.
Вымирающий вид, поскольку у сегодняшних васянов и васян-бизнесов давно уже нет необходимости (да и возможности нормально) держать сайтик. Страничка в мордокниге, группка в всосапе, торговлишка - через мракетплейс.
А вот почему модная-современная-девляпляпляп разработка выбирает постгрез вместо mysql, а потом рожает чудовищ, там где sqlite был бы как раз - этого вот я действительно не могу понять.
(случай убера оставим за скобками, поскольку он уникальный а вопросы задать там некому. К тому же это компания п-сов.)
>А вот почему модная-современная-девляпляпляп разработка выбирает постгрез вместо mysql, а потом рожает чудовищСчитается, что там фич больше. Типа, авось пригодятся в будущем. Лично я не сторонник такого подхода, если что. Но рациональное звено в нём есть.
>там где sqlite был бы как раз - этого вот я действительно не могу понять.
Сомневаюсь, что в многопользовательской среде, где больше одного писателя, sqlite применим без костылей в виде самописного агента. Но может вы о чём-то другом.
Ну есть же рейтинг популярности СУБД. Очень легко ищутся. Попробуйте, что ли.
Mysql не заброшенная база. У неё же бампится версия.
Инновации ради инноваций.
Поддержка сборки другими компилями на Солярисе это киллерфича.
https://ru.wikipedia.org/wiki/Oracle#Oracle_в_СССР_и_СНГ
Лучшая база из бесплатных.
Даже лучше sqlite?
Sqlite худшее что можно придумать бай дизайн.
Для многопользовательской среды - однозначно лучше. Для однопользовательской - зависит от сценария использования.
Неверное сравнение. Нужно сравнивать надстройку над Sqlite сетевую. Уверен такая существует. А там уже бенчмарки, слеты залеты и т.д. проверять и сравнивать.
По базе на поток записи? Тогда смысл немного пропадёт. Есть LiteFS, но FUSE-based как ты понимаешь решает другие задачи. Да и любая дрянь на го будет специфической. Вот sqlite вполне успешно заменяет mysql там где он применяется, нормальное сравнение. Промышленные высоконагруженные базы заменить сложнее, mysql туда только в очень специфических случаях впихивают.
Скорее лучшая из бесплатных - это MariaDB
Чем тебе mysql не бесплатная? Чем тебе mariadb enterprise не платная?
Скорее вопрос зачем брать какую-то марию сделанную мошенническим способом? Продадим ораклу базу, а сами под предлогом защиты свободы форкнем её и будем продавать ент версию.
Percona поинтересней будет
BerkeleyDB получше будет.
CSV флэт файл еще лучше
Почему postgresql используется чуть ли не больше?
Свежие данные говорят что mysql второе место постгря четвертое среди всех баз. Какие тут ещё могут быть вопросы? https://pypl.github.io/DB.html
Ну тут, кстати, относительно честная статистика в отличии от доли рынка браузеров, где хром на первом месте. Дело в том, что СУБД выбирают и ставят осознанно, а браузер юзают тот, к-й предустановлен и часто люди (а таких большинство) вообще не понимают что это такое, для них это просто Интернет и они даже не заметят разницы если его подменить на Firefox (лично проверял - спросили только куда закладки подевались, и даже глазом не повели что это другой браузер)
SAP HANA : Как лодку назовёшь... В русскоязычном сегменте успех "обеспечен".
SAP одна из самых дорогостоящих компаний в Европе.
>В русскоязычном сегменте успех "обеспечен".Как будто этот сегмент кому-то интересен в наши дни.
Это смотря как считать. Если считать все ВордПрессы, тогда да. Но тогда то самая популярная sqlite - в каждом Android-смартфоне есть. А если по объему данных - картинка будет другой.
А, там вообще по запросам в гугл. Такая себе метрика
PostgreSQL плохо подходит для большого количества соединений из-за идеологии форка на каждое соединение. Понятно, что есть pgbounce и т.п., но это не панацея, так как, для примера, не решает проблемы с объектами, живущими до окончания сессии.
Поэтому для легковесных по логике приложений MySQL выглядит предпочтительней, проигрывая PostgreSQL при сложной логике уровня ERP.
Вспоминать холивар по поводу отсутствия undo буфера в PostgreSQL не хочу, так как эта проблема решаема при желании.
А вообще, если кто-то заявляет, что А лучше Б не указав круг задач, для которых это выражение истинно, то этот кто-то просто дилетант и обращать внимание на его заявления смысла не имеет. Например, я сталкивался с задачами, где PostgreSQL оказывался заметно эффективней MS SQL, хотя, если считать среднюю температуру по больнице, особенно с учетом 1С, то MS SQL обеспечивает большую производительность.
Это смотря что за приложение. Если php какой-нибудь, с коннектом на каждый http-запрос, то это проблема (но тут pgbouncer проблему решает), а в приложении, паралельно обрабатывающем массу запросов по событийной модели, можно и небольшим количеством соединений обойтись.
> Это смотря что за приложение. Если php какой-нибудь, с коннектом на каждый
> http-запрос, то это проблема (но тут pgbouncer проблему решает)И как pgbouncer решает проблему с объектами, живущими до окончания сессии?
> в приложении, паралельно обрабатывающем массу запросов по событийной модели, можно и небольшим
> количеством соединений обойтись.Но потребуется решать все те же проблемы, начиная с вороха SET перед каждым запросом и опять заканчивая проблемой с объектами, живущими до окончания сессии.
Как ни крути, но сессия по определению имеет состояние, которое может очень сильно влиять на выполнение запросов.
Проблема решается очень просто - не использовать их. Такая логика прекрасно переносится на уровень приложения.
> Проблема решается очень просто - не использовать их.Вы предлагаете обходится без временных таблиц, pg_variables, различных конфигурационных параметров и т.п.?
А Вы уверены, что ведете речь о задачах для RDBMS, раз Вам даже SET enable_seqscan = 0 никогда не требуется, а SET search_path ни на что не влияет?
SET LOCAL вполне подойдёт. Временные таблицы вот ни разу в жизни не понадобились, всегда хватало CTE.
> SET LOCAL вполне подойдёт.Который, во-первых, ограничен одной транзакцией, что далеко не всегда приемлемо. Во-вторых, никак не страхует от того, что очередной запрос будет без LOCAL и повлияет на все последующие запросы в этом соединении. А в-третьих, требует явного использования транзакций, что вне хранимых процедур чревато неприятными последствиями.
> Временные таблицы вот ни разу в жизни не
> понадобились, всегда хватало CTE.Результат CTE не индексируем, поэтому область применения CTE весьма ограничена.
Так что если Вам всегда его хватало, то PostgreSQL Вам точно не нужен )))
1C лудше
Firebird лучше.
Так её кто-то пользует в продакшн? Или все ушли на постгрес?
Uber — причины перехода с Postgres на MySQL
https://habr.com/ru/companies/slurm/articles/322624/
Актуальная статья 2017 года. Так свежо.
Кстати, пг уже исправил всё (или почти всё).
> Актуальная статья 2017 года. Так свежо.
> Кстати, пг уже исправил всё (или почти всё).Всего 10 лет, ну ты чего.
Дык жизнь - это то что происходит вокруг и сейчас!(С) ;)
далеко не все, и некоторое в принципе не исправимо
у меня мария в проде, постгрес не быстрее, может около 5-8% в зависимости от задач, держу код постгрес-совместимым, но пока не пригодилось, причин переезжать не было
> Так её кто-то пользует в продакшн? Или все ушли на постгрес?Ваш вопрос приблизительно переводится как:
- Так ложку кто-то пользует в продакшн? Или все ушли на половник?ORDBMS vs RDBMS
Непонятно, зачем всё это нужно, когда есть надёжные и проверенные временем решения: dBase, FoxPro, Paradox, Clipper и (прости господи) Microsoft Access.
И оно, всё перечисленное - уже даже и не воняет :)
А для чего оно могло быть использовано уже давно под SQLite :-p
Не знаю о чем ты.
Вот про dBase открываю в Википедии, а там...Stable release: dBASE 2019 / 2019.