Вышел MySQL 4.0.27

>сервер и приложения mysql не запускались на OS Solaris 8/9/10 x86 на машинах с процессором Pentium III.

Да, классная и очень зрелая СУБД, ничего не скажешь.

>anonymous (*) (15.05.2006 14:10:08)

Да, классный и очень зрелый специалист, ничего не скажешь.

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

MySQL sucks - PostgreSQL rulezzz. Комерческая конторка - выезжающая на толковом маркетинге.... Для тех у кого весь sql ограничен insert/select/update пойдет

> Да, классный и очень зрелый специалист, ничего не скажешь.

А ты попробуй почитать changelog. Особенно наличие след. багов говорит о "зрелости" субд: * The server crashed when one thread resized the query cache while another thread was using it. * A concurrency problem for CREATE ... SELECT could cause a server crashю * Queries against a MERGE table that has a composite index could produce incorrect results. * SELECT DISTINCT with a GROUP BY clause caused a server crash. * An UPDATE statement which tried to update a column with a name beginning with an asterisk would cause the server to crash. * BIT_COUNT() could return an incorrect value for right table columns in a LEFT JOIN.

Продолжать? Там таких CRASH, INCORRECT VALUE довольно много.

Уже какая версия, а все что выходит за обычный SELECT нифига толком не работает. Детские болезни переходящие в старческие.

Ура. Это хорошая быстрая ветка MySQL. Не надо её забывать.

>все прогрессивное человечество уже давно сидит на 4.1 как минимум.

Вам глюки ловить. Нам с 4.0.XX работать. Вам успехов.

ошибки в запросах select с regexp, если были синтаксические ошибки в регвыражениях , вешало mysql вплоть до рестарта

>все прогрессивное человечество уже давно сидит на 4.1 как минимум. Хотя багфикс релиз не может не радовать тех, кто в танке.

К сожалению разработчики 4.1.x, 5.0 и тд, ну уж очень что-то намудрили с кодировками. Так что когда есть базы и на koi8, cp1251...utf8 лутше использовать 4.0.x

>К сожалению разработчики 4.1.x, 5.0 и тд, ну уж очень что-то намудрили с кодировками.

Единственный внятный способ работать с MySQL - это держать базу в UTF-8.

ИМХО, есть проекты, в которых не надо из "хорошо" стремиться сделать "как лучше". Была простенькая, стабильная и шустрая СУБД с SQL интерфейсом - MySQL 3.XX. Для некоторых задач - вполне подходящая СУБД.

Зачем надо было лезть во "взрослый" сегмент рынка - непонятно (хотя понятно, денег захотелось). Потому как оно сейчас и не особо взрослое и не особо стабильное и не всегда шустрое.

а я как-то 4.0 пропустил, с 3й сразу на 4.1 перепрыгнул, а сейчас везде 5.0

> Единственный внятный способ работать с MySQL - это держать базу в UTF-8.

я только так и делаю :)

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

хотя 99% - это cp1251+utf8 (в зависимости от того, на какой системе клиент)

>К сожалению разработчики 4.1.x, 5.0 и тд, ну уж очень что-то намудрили с кодировками.

Про 5.0 не знаю, а в 4.1.x не натыкался. Всё как часы работает при разных кодировках, как БД, так и клиента.

К сожалению, каждая следующая версия MySQL медленнее предыдущей. Так что 4.0 > 4.1 > 5.0 в смысле скорости. Кому это важно, а новые фичи не очень - тот сидит на 4.0.x

http://www.mysqlperformanceblog.com/mysql-performance-presentations/

Вот здесь можно посмотреть о производительности MySQL 4.1 vs 5.0

>Про 5.0 не знаю, а в 4.1.x не натыкался. Всё как часы работает при разных кодировках, как БД, так и клиента.

У меня была заморочка, то даже если ставишь в конфиге cp1251, саму БД он хранит в utf8. И конечно будет тебе отдавать ее как ты попросишь, но надо еще попросить в нужно кодировке. Но не все web приложения умеют это делать ) Поэтому получалось, что он отдавал ее в utf8. На collation в свойствах БД он (mysql) успешно забивал. Я долго мучился с этим багом, но единственное что смог придумать, так это выставление принудительной кодировки: skip-character-set-client-handshake. Может конечно я его неасилил? :)