The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Доступна СУБД MySQL 9.0.0

02.07.2024 09:42

Компания Oracle сформировала новую ветку СУБД MySQL 9.0.0. Сборки MySQL Community Server 9.0.0 подготовлены для всех основных дистрибутивов Linux, FreeBSD, macOS и Windows. В рамках внедрённой в прошлом году модели формирования релизов, MySQL 9.0 отнесён к веткам "Innovation", к которым также будут отнесены следующие значительные релизы MySQL 9.1 и 9.2. Innovation-ветки рекомендованы для тех, кто хочет раньше получать доступ к новой функциональности, публикуются каждые 3 месяца и поддерживаются только до публикации следующего значительного релиза (например, после появления ветки 9.1 будет прекращена поддержка ветки 9.0). Примерно через год планируют сформировать LTS-релиз, который будет рекомендован для внедрений, которым необходима предсказуемость и длительное сохранение неизменного поведения. Следом за LTS-веткой будет сформирована новая Innovation-ветка - MySQL 10.0.

Основные изменения в MySQL 9.0:

  • При выполнении конструкции "EXPLAIN ANALYZE INTO" добавлена возможность сохранения вывода в формате JSON в пользовательскую переменную, которая затем может использоваться в качестве аргумента в функциях для работы с JSON.
    
       EXPLAIN ANALYZE FORMAT=JSON INTO @variable select_stmt
    
  • Разрешено оформление выражений "CREATE EVENT", "ALTER EVENT" и "DROP EVENT" в виде параметризованных запросов внутри хранимых процедур. Создание параметризованного запроса осуществляется с использованием выражения PREPARE, а выполнение - выражения EXECUTE.
    
       CREATE PROCEDURE sp(n INT)
       BEGIN
         SET @s1 = "CREATE EVENT e ON SCHEDULE EVERY ";
         SET @s2 = " SECOND
              STARTS CURRENT_TIMESTAMP + INTERVAL 10 SECOND
              ENDS CURRENT_TIMESTAMP + INTERVAL 2 MINUTE
              ON COMPLETION PRESERVE
              DO
              INSERT INTO d.t VALUES ROW(NULL, NOW(), FLOOR(RAND()*100))";
      
         SET @s = CONCAT(@s1, n, @s2);
         PREPARE ps FROM @s;
         EXECUTE ps;
         DEALLOCATE PREPARE ps;
       END
    
  • Добавлены две новые системные таблицы, содержащие сведения о системных переменных: variables_metadata - содержит информацию об именах, области действия, типах и диапазонах значений всех поддерживаемых MySQL-сервером системных переменных; global_variable_attributes - содержит значения атрибутов, выставленных для глобальных переменных, таких как offline_mode и read_only.
  • Удалён ранее объявленный устаревшим серверный плагин mysql_native_password, обеспечивающий аутентификацию при помощи паролей. Вместо mysql_native_password рекомендуется перейти на использование плагина caching_sha2_password, применяющего для хэширования алгоритм SHA2 вместо SHA1.
  • Добавлено 15 переменных для настройки и инспектирования движка MLE (Multilingual Engine Component), позволяющего использовать в хранимых процедурах и функциях код на языках, отличных от SQL.


  1. Главная ссылка к новости (https://dev.mysql.com/download...)
  2. OpenNews: Стабильный выпуск СУБД MariaDB 11.4
  3. OpenNews: Стабильный релиз СУБД MySQL 8.0
  4. OpenNews: Доступна СУБД MySQL 8.4.0 LTS
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/61476-mysql
Ключевые слова: mysql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (73) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 10:01, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Скудновато для мажорной версии
     
     
  • 2.5, Аноним (5), 10:14, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Давно уже все пренебрегают семантическим версионированием и это скорее циферки для конечного пользователя
     
     
  • 3.10, Аноним (10), 10:35, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это уже даже не маркетинг. А обезьянничество. Просто все так сделали и я тоже так сделаю.
     
  • 2.13, Аноним (13), 10:44, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А это по сути не мажорная версия. Это изменение схемы версионирования.

    Они решили, что 8.x будет stable, а в 9.x будут экспериментальные фичи. Короче, 8.x это RHEL, а 9.x это Fedora :-)

     
     
  • 3.19, Аноним (19), 11:25, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это просто накрутка номера версии.
     
  • 2.23, Аноним (23), 13:05, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Удаление mysql_native_password - достаточно большое несовместимое изменение, чтобы прибавить единичку к мажорной версии.
     
  • 2.57, ИмяХ (ok), 22:55, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Их тоже хромозилла покусала
     

  • 1.2, FSA (??), 10:07, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    После PostgreSQL как-то не очень...
     
     
  • 2.4, Аноним (4), 10:12, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    не работает с эсодин? :-)
     
     
  • 3.11, Аноним (11), 10:39, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А есть с чем сабж работает? Не "посмотреть", а именно работает?
     
     
  • 4.14, Аноним (14), 10:59, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С вордпрессом же.
     
  • 3.24, FSA (??), 13:16, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > не работает с эсодин? :-)

    Нет. Вообще с 1С дел не имею. Я больше на PHP пишу. Могу напрямую с базой работать без всяких ORM. При чём что с PostgreSQL, что с MySQL. Просто смотришь на некоторые привычные вещи, а они только в новых версиях MySQL. А эта версии ещё не скоро в дистрибутивах появятся.

     
     
  • 4.29, Аноним (29), 13:35, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –6 +/
    > А эта версии ещё не скоро в дистрибутивах появятся.

    Именно эту проблему решает docker.

     
     
  • 5.52, Аноним (52), 18:13, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хм... Читал, что СУБД в Docker - не для промышленного применения.
    Это не так?
     
  • 4.34, kai3341 (ok), 14:01, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Я больше на PHP пишу.

    Время стереотипов про PHP-шников! (шутка)

    > Могу напрямую с базой работать без всяких ORM.

    Все так могут. Сложность в том, чтобы найти ORM/QueryBuilder, который будет заниматься миграциями, гарантиями корректности, и при этом не будет бесить своей ограниченностью

    > не скоро в дистрибутивах появятся

    А вот неосиляторство докера в 2024 -- это большой грех. Страшнее только то, что разработкой ты занимаешься тоже без докера -- с вагоном мусора на хост-системе

     
     
  • 5.40, Аноним (13), 15:00, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Сложность в том, чтобы найти ORM/QueryBuilder

    Если про PHP, то Spiral ORM.

    Да, там надо осилить, это цена гибкости.

     
     
  • 6.41, Аноним (13), 15:01, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Точнее, Cycle ORM, из фреймворка Spiral (от самого фреймворка зависимостей нет.)
     
  • 6.56, Аноним (56), 22:21, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В JS/TS Sequelize, Prisma. Ну, мб, typeorm.
     
     
  • 7.66, Аноним (13), 07:58, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Sequelize и TypeORM не поддерживают концепцю Unit of Work, что серьезное ограничение, поскольку приходится эмулировать его вручную, что далеко не всегда тривиально. Единственная полноценная на js/ts, которую я видел, носит странное название Mikro-ORM, хотя давно уже куда более навороченная, чем остальные.
     
  • 5.61, Вы забыли заполнить поле Name (?), 02:06, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >  будет заниматься миграциями, гарантиями корректности,

    Миграцию можно писать на SQL. Гарантию корректности дает тоже SQL. Единственное, что последнее происходит в рантайме и чем может помочь какой-нибудь query builder, так это проверкой во время компиляции.

     
     
  • 6.72, Аноним (13), 09:17, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Query builder нужен для того, чтобы удобно собирать запрос по частям. Например, могут быть классы или функции Criteria..., которые добавляют условия фильтров в запрос. Можно, конечно, вручную таскать части запроса и биндинги, и потом всё аккуратно собирать, но это и получится написание своего частного случая Query Builder.

    А ORM нужны вообще для другого. Для чего они нужны - следует из названия. Для двустороннего маппинга между объектами (или, в случае неООП, структурами или кастомными типами) и структурой данных в РСУБД. Можно в первом приближении сказать, что это такой serialize/unserialize в РСУБД.

     
  • 4.55, Аноним (55), 22:09, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Просто смотришь на некоторые привычные вещи, а они только в новых версиях MySQL. А эта версии ещё не скоро в дистрибутивах появятся.

    Да вы что. В дистрибутивах новые версии появляются на следующий день. Надеюсь вы не используете и не считаете дистрибутивом какой-нибудь дебиан олдстабле или центос?

     
  • 2.31, penetrator (?), 13:35, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    аргументы будут? давай по пунктам, а то мы все прекрасно помним как Uber переходил с постгреса на мускл

    и да как там в постгрес мультимастер кластера завезли уже?

     
     
  • 3.42, Аноним (42), 15:05, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    сразу видно, что ты понятия не имеешь, что такое мускульный мультимастер и в продакшене ты его никогда не видел
     
     
  • 4.43, Tron is Whistling (?), 15:36, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А чего с ним не так? Так что с постгрызом?
     
  • 4.47, penetrator (?), 17:13, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ты главное верь в это )))
     
  • 3.58, Аноним (55), 22:57, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Так неосиляторов из убера уже давно разбомбили.
     
     
  • 4.60, penetrator (?), 23:46, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Так неосиляторов из убера уже давно разбомбили.

    никто их не разбомбил, достаточно почитать ответ статью самих разработчиков постгреса

     
  • 3.69, User (??), 08:46, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну, as for me - multimaster cluster достаточно нишевая штука так-то. Не то, чтобы "ненужно!" - но нужно не только лишь всем и очень-очень часто более, чем компенсируется на уровне архитектуры.
     
     
  • 4.79, penetrator (?), 21:34, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну, as for me - multimaster cluster достаточно нишевая штука так-то. Не
    > то, чтобы "ненужно!" - но нужно не только лишь всем и
    > очень-очень часто более, чем компенсируется на уровне архитектуры.

    "не компенсируется", и СУБД умеющая такое и есть в таком случае часть архитектуры

    технические решения для таких СУБД вырабатываются годами, никто не будет делать это в отдельном взятом проекте, а потому ты наверное хотел сказать, что отсутствие консистенстности между распределенными нодами приводит к обрезанию в функциональности и закостыливанию каких-то вещей

    > достаточно нишевая штука

    везде где требуется HA и/или sharding, часто используется много где, другое дело что проектов где это не нужно и можно расти вертикально намного больше, так с этим не спорит никто

    вопрос в другом - вот вырос ты из постгреса, и не только потому что локально ворочаться сложно, а потому что  открылся офис ну например в Сингапуре или Индии, он куда стучаться будет? с какой латенси? 200-300ms в лучшем случае

    с чего бы вдруг гуглу Spanner понадобился ))))

     
     
  • 5.90, User (??), 08:36, 04/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да оспыдя. Кому надо - задолго до "вырастания" из postgres'а уже понабрали кто cassandra'у, кто mongo, кто clickhouse, даже блин redis с георепликацией видел - а вот ар-ригиналов с mysql - нет. В бизнесухе - нет. В чистой вебне - не знаю, может и осталось где с тех еще времен...

     
  • 2.62, Аноним (62), 03:00, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сколько лет в теме, а постгрес видел пару раз и то у очень больших оригиналов.
     
     
  • 3.80, penetrator (?), 22:05, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Сколько лет в теме, а постгрес видел пару раз и то у
    > очень больших оригиналов.

    В РФ популярна, исторически )))

     
  • 2.88, Аноним (88), 07:10, 04/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Зато мастер-мастер репликация работает.
     

  • 1.3, жырымагнап (ok), 10:09, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Чем это лучше Firebird?
     
     
  • 2.7, Аноним (10), 10:16, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Тем что FoxPro.
     
  • 2.44, Аноним (44), 16:04, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А что у Firebird за мутная лицензия IDPL Interbase-1.0? Как она совместима с проектами под GPL? MySQL совместим.
     
  • 2.45, _ (??), 16:25, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Чем это лучше Firebird?

    Ну бэкапы к примеру _точно_ восстанавливаются, а не как у этих :)

     

  • 1.6, Аноним (10), 10:15, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Версия ради версии. Кто объяснит какой в этом высокий смысл? Это даже не коммерческий продукт чтобы его продать или обогнать конкурентов. В своей нише у майсикуэля нет конкурентов.
     
     
  • 2.8, Кекарь (?), 10:23, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А как же MariaDB?
     
  • 2.12, Аноним (11), 10:40, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В своей нише у майсикуэля нет конкурентов.

    Неуловимый Джо.

     
     
  • 3.15, Аноним (14), 11:00, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Зависть.
     
     
  • 4.22, Аноним (29), 12:59, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну завидуйте, ораклята.

    При наличии универсальных РСУБД, таких, как постгрес, востребованность мускуля крайне сомнительно.

     
     
  • 5.32, penetrator (?), 13:38, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    постгрес вообще не универсальная субд, это жалкое зрелище

    у оракла есть мультимастер, как кстати и у мускула, притом у последнего два варианта и оба бесплатных

     
     
  • 6.71, User (??), 08:53, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. Просто это не рСУБД, а "объектно-реляционная СУБД" - которая достаточно хорошо "натягивается" в том числе и на нишу чистых реляционок. Не идеально, но прям "хорошо".
     
     
  • 7.73, Аноним (13), 09:18, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ой, да не надо. Постгрес - самая обычная классическая РСУБД. Мелкая, редко нужная фича в виде наследования таблиц ничего не меняет.
     
     
  • 8.75, User (??), 11:43, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Наследование таблиц, наследование типов, перегрузка функций, развитый тулинг для... текст свёрнут, показать
     
     
  • 9.87, Аноним (87), 00:12, 04/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Объектная БД - это совсем про другое, это типа Cach 233 , если кто помнит такую... текст свёрнут, показать
     
  • 7.81, penetrator (?), 22:07, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    поэтому она должна паршивенько решать задачу масштабирования с реляционными данными, что-то оракл с его PL-SQL так не думает
     
  • 2.25, FSA (??), 13:18, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > В своей нише у майсикуэля нет конкурентов.

    Это что за ниша такая, где MySQL не может заменить PostgreSQL? На серьёзных проектах скорее наоборот, их MySQL может не потянуть. А вот в обратную сторону даже представить себе не могу что это такое может быть.

     
     
  • 3.33, penetrator (?), 13:41, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    geographically distributed synchronous replication

    от одного сочетания страшно, а у мускула есть 2 реализации

    постгрес - инвалид по сравнению с mysql, который тоже не идеален, но в этом плане как у всех

     
     
  • 4.70, User (??), 08:51, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нукагбэда, но вот NoSQL в этой нише чувствуют себя прям сильно-сильно лучше - и ситуаций, когда нельзя разделить "данные" для которых вот это вот все имеет смысл от "реляционных метаданных" не то, чтобы много - и как бы это сказать... legacy оне.
     
     
  • 5.78, penetrator (?), 21:20, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > NoSQL в этой нише чувствуют себя прям сильно-сильно лучше

    нет, не чувствуют, там нет консистентности даже в задекларированных возможностях неговоря уже о реальных возможностях

    в некоторых отдельных случаях можно увидеть транзакции в монге, можно выбирать стратегии репликации, но в целом все плохо

     
     
  • 6.89, User (??), 08:12, 04/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> NoSQL в этой нише чувствуют себя прям сильно-сильно лучше
    > нет, не чувствуют, там нет консистентности даже в задекларированных возможностях неговоря
    > уже о реальных возможностях
    > в некоторых отдельных случаях можно увидеть транзакции в монге, можно выбирать стратегии
    > репликации, но в целом все плохо

    Охтыжблин. Мужики-то не знают!(Ц)
    В тех 2,5 случаях, когда тебе _действительно_ нужен синхронно геореплицированный ACID на весь объем обрабатываемых данных - у тебя стоит oracle или хотя бы mssql. В 98% остальных кейсов тебя вполне устроит BASE для основного объема данных и ACID для совочка метаданных  - а то и вовсе какой transactional outbox поверх кафки - depends on.

     
  • 3.39, Аноним (13), 14:18, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Все случаи, где нужен обобщенный инвертированный индекс. Например, поиск по произвольному множеству атрибутов в каталоге типа Яндекс-маркета. С MySQL придется либо делать поиск во внешней специализированной базе (со всеми проблемами синхронизации), либо костылить поверх полнотекстового поиска, кодируя все атрибуты "словами" с отключением морфологии.
     
     
  • 4.48, penetrator (?), 17:36, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    так это и делается полнотекстовым поиском, индексы нормально не работают если значение не начинается с искомого слова

    если у постгреса есть что-то из каропки, то это не значит, что это must have

    есть вещи которые в БД и только в БД должны быть и никако по-другому нереализуемы, а есть вещи которые в БД существуют просто как сахар, и такой шляпы там дофига не только GIN, но теперь и RUM, а еще GIST

    но я уж лучше SolR или Elastic они хотя бы тоже мастштабируется горизонтально

     
     
  • 5.50, Аноним (13), 17:52, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем полнотекстовый поиск для информации, которая изначально естественным образом представляется как Set[Int]?

    GIN как раз для этого, изначально делался вместе с hstore для обработки астрономических данных, разреженных просто по своей природе.

    Непонятно, почему вдруг btree мастхэв, а inverted index - нет. Это два разных индекса для решения двух разных задач.

    Горизонтальное масштабирование же далеко не всегда нужно, и отдавать его на откуп СУБД - тоже не всегда разумно: если есть критерий, по которому легко пошардить ручками на уровне приложения, такая реализация будет заведомо эффективнее.

     
     
  • 6.53, penetrator (?), 18:24, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    а если я в описании хочу поискать? в том числе произвольные словоформы?

    и зачем мне искать текст фильтра, если мне нужен код фильтра?

    да и в целом вот не вижу я причины почему более универсальное решение должно замениться менее универсальным, так еще интгрерированным в СУБД со своими плюсами, но и минусами

    > если есть критерий, по которому легко пошардить ручками на уровне приложения, такая реализация будет заведомо эффективнее.

    не будет эффективней
    не легко прошардить
    а про консистентность уже вообще промолчу

     
     
  • 7.54, Аноним (13), 19:18, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если ты хочешь поискать в описании, для этого делается полнотекстовый поиск по описанию, для этого есть fts.

    А еще ты можешь хотеть отсортировать по цене. Это btree.

    Прикинь, для каждой задачи свой тип индекса.

    > не будет эффективней

    От рук зависит. В одном конкуренте Фейсбука очень эффективно было, разведка говорит, что и в самом Фейсбуке примерно так же.

    > а про консистентность уже вообще промолчу

    А какая может быть неконсистентность при шардинге? Шардинг от репликации не отличаем, зато рассуждаем про эффективность, вау

     
     
  • 8.59, penetrator (?), 23:45, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я этот бред даже коментировать не вижу смысла, удачи... текст свёрнут, показать
     
  • 4.49, penetrator (?), 17:37, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > поиск по произвольному множеству атрибутов в каталоге

    это кстати пример корявого использования

     
     
  • 5.51, Аноним (13), 17:53, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А чего в нем корявово? Прямое использование по назначению.

    Инвертированный индекс - это указатель: в каких строках встречается данное значение. Ровно то, что и нужно.

     

  • 1.16, Аноним (16), 11:11, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Зачем нужно MySQL 9.0, когда есть MariaDB 11.4?
     
     
  • 2.17, Массоны Рептилоиды (?), 11:15, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Зачем нужно MySQL 9.0, когда есть MariaDB 11.4?

    Слабаки! PostgreSQL 16.3

     
     
  • 3.18, Аноним (19), 11:25, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Oracle Database 23ai смотрит на вас как вы сами знаете на что.
     
     
  • 4.20, Аноним (20), 11:53, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +6 +/
    MS Access 2404 на вас даже не смотрит
     
     
  • 5.26, Аноним (26), 13:28, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что он при нагрузках которые успешно тянут все вышеназванные уже загнулся в кровавых соплях и глаза закатил
     
  • 2.21, Ilya Indigo (ok), 12:46, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://jira.mariadb.org/browse/MDEV-11588
    Когда этот баг исправят или хотя бы начнут им заниматься, тогда и упоминайте MariaDB!
     
     
  • 3.37, kai3341 (ok), 14:10, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > https://jira.mariadb.org/browse/MDEV-11588

    Ну кстати в оракле так было. ХЗ, актуально ли до сих пор

     
     
  • 4.38, Ilya Indigo (ok), 14:12, 02/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> https://jira.mariadb.org/browse/MDEV-11588
    > Ну кстати в оракле так было. ХЗ, актуально ли до сих пор

    В MySQL лет 10 назад это тоже было, но это более 10 лет назад исправили.

     
  • 3.74, Аноним (13), 09:24, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну давайте откровенно, те, кто на это наталкиваются, писали некорректные запросы в старых MySQL, не имевших даже опции ONLY_FULL_GROUP_BY и при неоднозначном GROUP BY просто возвращавших первое, что попалось, а работало это просто потому что в данном конкретном случае конфликтов не возникало. А потом завезли строгий SQL и всё поломалось.

    PostgreSQL тоже распознает functionally dependent только в простейшем частном случае наличия PK в GROUP BY, и ничего, никто не рассыпался вручную перечислить столбцы в GROUP BY.

     

  • 1.27, Аноним (26), 13:29, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что как там с репликацией?
     
     
  • 2.67, bOOster (ok), 08:17, 03/07/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Репликация репликации рознь. Научитесь точнее формулировать свои мысли.
     

  • 1.77, pda (ok), 13:12, 03/07/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > MySQL 9.0.0

    Боромир (MariaDB) был бы уже 10.0.0 (По факту 11.x.x).

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру