LINUX.ORG.RU
 

MySQL 4.1.0


0

0

9-го апреля стала доступна для скачивания 1-я alpha-версия нестабильной ветки MySQL 4.1

Некоторые из нововведений:
- поддержка вложеных запросов вида:
SELECT * FROM t1 WHERE t1.a=(SELECT t2.b FROM t2);
SELECT * FROM t1 WHERE (1,2,3) IN (SELECT a,b,c FROM t2);
- производные (derived) таблицы вида:
SELECT t1.a FROM t1, (SELECT * FROM t2) t3 WHERE t1.a=t3.a;
- расширенная поддержка UTF-8;
- возможность устанавливать кодировку для каждого столбца, таблицы и базы данных;
- поддержка OpenGIS (географические данные).

>>> Подробности

ЗАСТАВЬ КОМПЬЮТЕР ПОЛИВАТЬ ОГОРОД

автоматизация своими руками: электроприборы под контролем компьютера
beware of programmers who carry screwdrivers!
http://www.unicontrollers.com/products/unc01x

[#]  

Re: MySQL 4.1.0

walrus (*) (2003-04-19 22:43:12.018796):

> Практика - критерий истины. mysql обьективно быстрее большинства других DBMS

Случайно заглянул на http://www.mysql.com/doc/en/Developers.html и увидел:

Aleksey (Walrus) Kishkin and Alexey (Ranger) Stroganov * Benchmarks design and analysis. * Maintenance of the MySQL test suite.

Спорить с профессиональным MySQL benchmarketer'ом не буду --- знаю способы гораздо более продуктивно потратить время. ;

anonymous ()
[#]  

Re: MySQL 4.1.0

раз уж тут есть "казачок" из Мыскль АБэ, то ему пару вопросов:

> надеюсь вы себе отдаете отчет, что "засунутые" внутрь базы вычисления будут _интерпретироваться_. И если вы попросите свою СУБД выдать вам миллион значений - интерпретация будет самым проигрышным вариантом по скорости.

"Зелен виноград"? ;)

Если хранимые процедуры, триггеры и т.п. - такой отстой, то почему Мыскль АБэ так рвёт пупок реализовать их в следующей версии и так бьёт себя кулаками во впалую грудь по этому поводу?

Помните как раньше: в доке от Мыскля приведена куча причин, почему не надо использовать внешние ключи. Потом внешние ключи реализуют, и глава из доки таинственно исчезает. Хе-хе. И про транзакции похожая история...

> И мне кстати очень жаль, что они не принимали участие, потому. что по предварительным прикидкам - они бы обогнали многие толстые и снобистски настроенные коммерческие базы.

Если в Мыскль Абэ так хорошо относятся к Постгресу, то почему до сих пор не убрали или не привели в пристойный вид вот это говно: http://www.mysql.com/doc/en/MySQL-PostgreSQL_goals.html http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html

Я знаю, причём не из личной переписки, а из вполне публичных списков рассылки, что разработчики Постгреса Мыскль Абэ неоднократно об этом просили. Безрезультатно, естественно.

> Но если это что-то более серьезное - пишете EJB или CORBA или даже rpc (xmlrpc) сервер, который _один_ лезет в базу.

Представляю себе типичного "мускул"истого товарища, который из всех книг по СУБД осилил мануал MySQL (и тот до середины), из всех языков - ПэХэПэ до конструкции switch, пишущим EJB, CORBA или даже xmlrpc сервер. ;)

anonymous ()
[#] Ответ на: Re: MySQL 4.1.0 от anonymous 20.04.2003 21:29:10  

qmail/sendmail: war number 223455

<цитата> > надеюсь вы себе отдаете отчет, что "засунутые" внутрь базы вычисления будут _интерпретироваться_. И если вы попросите свою СУБД выдать вам миллион значений - интерпретация будет самым проигрышным вариантом по скорости.

"Зелен виноград"? ;) </цитата>

Странный вы человек.. Вот добавят в 5 версии sp в mysql и что изменится? перестанут интерпретироваться все хранимые процедуры во всех СУБД? Бездумное применение таких средств всегда вредило и будет вредить, поэтому их наличие/отсутствие рассматривать как аргумент не стоит. О чем и было сказано.

* ()
[#] Ответ на: Re: MySQL 4.1.0 от anonymous 20.04.2003 21:29:10  

mysql war

<цитата> Если в Мыскль Абэ так хорошо относятся к Постгресу, то почему до сих пор не убрали или не привели в пристойный вид вот это говно: http://www.mysql.com/doc/en/MySQL-PostgreSQL_goals.html http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html </цитата>

В первой ссылке вообше нет ничего обидного для postgres - там дана разница в процессе разработки. Во второй ссылке есть устаревшие моменты (типа vacuum) однако подавляющее пунктов в том списке - актуальны. Так что документ нуждается в чистке - всего лишь (и будет вычищен, когда doc team дойдет до этого пункта в TODO). И на будущее - еще одно слово, типа "говно" и вы будете спорить сами с собой. Я в таком обсуждении участвовать не буду.

* ()
[#] Ответ на: Re: MySQL 4.1.0 от anonymous 20.04.2003 21:29:10  

mysql war

<цитата> > Но если это что-то более серьезное - пишете EJB или CORBA или даже rpc (xmlrpc) сервер, который _один_ лезет в базу.

Представляю себе типичного "мускул"истого товарища, который из всех книг по СУБД осилил мануал MySQL (и тот до середины), из всех языков - ПэХэПэ до конструкции switch, пишущим EJB, CORBA или даже xmlrpc сервер. ;) </цитата>

Это похоже на желание "просто поругаться" когда аргументов не хватает.

* ()
[#] Ответ на: Re: MySQL 4.1.0 от anonymous 19.04.2003 22:10:08  

Re: Re: MySQL 4.1.0

>Мысль о том, что это происходит за счёт скорости усиленно продвигается в одном месте --- в маркетинговой пропаганде... эээ... документации MySQL.

И именно из-за потрясающе высокой скорости отработки запросов при организации биллинговой системы на базе Oracle расчетный модуль реализован на С, а не штатными средствами Oracle.

* ()
[#] Ответ на: Re: MySQL 4.1.0 от walrus 19.04.2003 22:39:47  

Re: Re: MySQL 4.1.0

> надеюсь вы себе отдаете отчет, что "засунутые" внутрь базы вычисления будут _интерпретироваться_.

Не надо утрировать. Хранимые процедуры могуть быть прекомпиленными. Или вы такой специалист, что этого не знали? Меня как-то не ломает критичный участок в postgres оформить в виде процедуры на SPI.

> И если вы попросите свою СУБД выдать вам миллион значений - интерпретация будет самым проигрышным вариантом по скорости.

Разботанивание миллионов строк на стороне принимающего тоже не фонтан. Вам же сказали, что если есть возможность тупую логику (типа CHECK) упрятать в базу, то ее надо туда прятать.

> Дело базы - хранить данные. И mysql справляется с этим на 5+

С вашим подходом к СУБД проще в файлах хранить и фильтровать их grep-ом. Во имя скорости вы теряете все хоть сколь-нибудь полезные свойства SQL.

ЗЫ. Еще одна пропаганда - и спорить будете сами с собой (c)

anonymous ()
[#] Ответ на: Re: Re: MySQL 4.1.0 от anonymous 22.04.2003 16:20:37  

Re: Re: Re: MySQL 4.1.0

<цитата>Не надо утрировать. Хранимые процедуры могуть быть прекомпиленными. Или вы такой специалист, что этого не знали? Меня как-то не ломает критичный участок в postgres оформить в виде процедуры на SPI. </цитата>

.. и завалить сервер по segmentation fault с непредсказуемыми последствиями для базы. А begin/end/abort уже можно из spi вызывать? А отлаживать такие процедуры? А, скажем, code coverage сделать при тестировании? Или вы вообще не тестируете свои программы?

<цитата> Вам же сказали, что если есть возможность тупую логику (типа CHECK) упрятать в базу, то ее надо туда прятать</цитата>

Вам же ответили что нет разницы если зарплата будет -5000 или 4666 если правильное значение 5000. Добавляя "тупую" проверку - вы получаете "почти правильный результат". И проверки в corba программе можно сделать гораздо умнее и эффективнее.

<цитата>Во имя скорости вы теряете все хоть сколь-нибудь полезные свойства SQL</цитата>

Если мне нужны _фичи_, я могу их реализовать в corba программе. Если мне нужна _скорость_, то я ее на медленной СУБД никак не получу (даже если в ней есть features на все случаи жизни)

<цитата>ЗЫ. Еще одна пропаганда - и спорить будете сами с собой (c)</цитата>

Пропаганда? ;-) Вы переоцениваете себя. Вы не представляете никакого интереса для mysql.

* ()