<?xml version="1.0" encoding="koi8-r"?>
<rss version="0.91">
<channel>
    <title>OpenForum RSS: Выпуск СУБД MySQL 9.5.0 </title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/138159.html</link>
    <description>Компания Oracle сформировала новую ветку СУБД MySQL 9.5.0. Сборки MySQL Community Server 9.5.0 подготовлены для всех основных дистрибутивов Linux, FreeBSD, macOS и Windows. В соответствии с внедрённой в 2023 году моделью формирования релизов, MySQL 9.5 отнесён к веткам &quot;Innovation&quot;.  Innovation-ветки рекомендованы для тех, кто хочет раньше получать доступ к новой функциональности, публикуются каждые 3 месяца и поддерживаются только до публикации следующего значительного релиза (например, после появления ветки 9.5 прекращена поддержка ветки 9.4). Зимой планируют сформировать LTS-релиз 9.6, рекомендованный для внедрений, которым необходима предсказуемость и длительное сохранение неизменного поведения. Следом за LTS-веткой будет сформирована новая Innovation-ветка - MySQL 10.0...&lt;br&gt;&lt;br&gt;Подробнее: https://www.opennet.ru/opennews/art.shtml?num=64100&lt;br&gt;</description>

<item>
    <title>Выпуск СУБД MySQL 9.5.0  (ptr)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/138159.html#56</link>
    <pubDate>Mon, 27 Oct 2025 12:53:27 GMT</pubDate>
    <description>&amp;gt; SET LOCAL вполне подойдёт.&lt;br&gt;&lt;br&gt;Который, во-первых, ограничен одной транзакцией, что далеко не всегда приемлемо. Во-вторых, никак не страхует от того, что очередной запрос будет без LOCAL и повлияет на все последующие запросы в этом соединении. А в-третьих, требует явного использования транзакций, что вне хранимых процедур чревато неприятными последствиями.&lt;br&gt;&lt;br&gt;&amp;gt; Временные таблицы вот ни разу в жизни не &lt;br&gt;&amp;gt; понадобились, всегда хватало CTE.&lt;br&gt;&lt;br&gt;Результат CTE не индексируем, поэтому область применения CTE весьма ограничена.&lt;br&gt;Так что если Вам всегда его хватало, то PostgreSQL Вам точно не нужен )))&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск СУБД MySQL 9.5.0  (Аноним)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/138159.html#55</link>
    <pubDate>Mon, 27 Oct 2025 11:28:26 GMT</pubDate>
    <description>SET LOCAL вполне подойдёт. Временные таблицы вот ни разу в жизни не понадобились, всегда хватало CTE.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск СУБД MySQL 9.5.0  (Чтото знающий)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/138159.html#54</link>
    <pubDate>Sun, 26 Oct 2025 23:12:53 GMT</pubDate>
    <description>&amp;gt;В русскоязычном сегменте успех &quot;обеспечен&quot;.&lt;br&gt;&lt;br&gt;Как будто этот сегмент кому-то интересен в наши дни. &lt;br&gt;</description>
</item>

<item>
    <title>Выпуск СУБД MySQL 9.5.0  (Чтото знающий)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/138159.html#53</link>
    <pubDate>Sun, 26 Oct 2025 23:07:16 GMT</pubDate>
    <description>&amp;gt;А вот почему модная-современная-девляпляпляп разработка выбирает постгрез вместо mysql, а потом рожает чудовищ&lt;br&gt;&lt;br&gt;Считается, что там фич больше. Типа, авось пригодятся в будущем. Лично я не сторонник такого подхода, если что. Но рациональное звено в нём есть. &lt;br&gt;&lt;br&gt;&amp;gt;там где sqlite был бы как раз - этого вот я действительно не могу понять.&lt;br&gt;&lt;br&gt;Сомневаюсь, что в многопользовательской среде, где больше одного писателя, sqlite применим без костылей в виде самописного агента. Но может вы о чём-то другом. &lt;br&gt;</description>
</item>

<item>
    <title>Выпуск СУБД MySQL 9.5.0  (Чтото знающий)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/138159.html#52</link>
    <pubDate>Sun, 26 Oct 2025 23:01:13 GMT</pubDate>
    <description>Ну есть же рейтинг популярности СУБД. Очень легко ищутся. Попробуйте, что ли. &lt;br&gt;</description>
</item>

<item>
    <title>Выпуск СУБД MySQL 9.5.0  (ptr)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/138159.html#51</link>
    <pubDate>Sun, 26 Oct 2025 11:35:33 GMT</pubDate>
    <description>&amp;gt; Проблема решается очень просто - не использовать их.&lt;br&gt;&lt;br&gt;Вы предлагаете обходится без временных таблиц, pg_variables, различных конфигурационных параметров  и т.п.?&lt;br&gt;А Вы уверены, что ведете речь о задачах для RDBMS, раз Вам даже SET enable_seqscan = 0 никогда не требуется, а SET search_path ни на что не влияет?&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск СУБД MySQL 9.5.0  (Аноним)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/138159.html#50</link>
    <pubDate>Sun, 26 Oct 2025 11:14:23 GMT</pubDate>
    <description>Проблема решается очень просто - не использовать их. Такая логика прекрасно переносится на уровень приложения.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск СУБД MySQL 9.5.0  (Аноним)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/138159.html#49</link>
    <pubDate>Sun, 26 Oct 2025 09:22:32 GMT</pubDate>
    <description>По базе на поток записи? Тогда смысл немного пропадёт. Есть LiteFS, но FUSE-based как ты понимаешь решает другие задачи. Да и любая дрянь на го будет специфической. Вот sqlite вполне успешно заменяет mysql там где он применяется, нормальное сравнение. Промышленные высоконагруженные базы заменить сложнее, mysql туда только в очень специфических случаях впихивают.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск СУБД MySQL 9.5.0  (Аноним)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/138159.html#48</link>
    <pubDate>Sun, 26 Oct 2025 09:05:17 GMT</pubDate>
    <description>Неверное сравнение. Нужно сравнивать надстройку над Sqlite сетевую. Уверен такая существует. А там уже бенчмарки, слеты залеты и т.д. проверять и сравнивать.&lt;br&gt;</description>
</item>

</channel>
</rss>
