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 (географические данные).

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



Проверено: green

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
()

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

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

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

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

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

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

Если в Мыскль Абэ так хорошо относятся к Постгресу, то почему до сих пор не убрали или не привели в пристойный вид вот это говно: 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
()
Ответ на: комментарий от anonymous

qmail/sendmail: war number 223455

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

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

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

walrus
()
Ответ на: комментарий от anonymous

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). И на будущее - еще одно слово, типа "говно" и вы будете спорить сами с собой. Я в таком обсуждении участвовать не буду.

walrus
()
Ответ на: комментарий от anonymous

mysql war

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

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

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

walrus
()
Ответ на: комментарий от anonymous

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

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

Ikonta_521
()
Ответ на: комментарий от walrus

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

walrus
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.