Собираем вопросы авторам MySQL - они ответят на PHPConf 2008

[confguru]

Собираем вопросы авторам MySQL - они ответят на PHPConf 2008

Появилась идея собрать самые лучшие вопросы авторам MySQL,
которые приедут пообщаться на PHPConf 2008.

Предлагаю собирать их в этом топике до 15 мая.

P.S. Чур вопрос - когда MySQL кластер будет работать с HDD не предлагать ;-)
P.S.S. Часть вопросов собрана тут http://habrahabr.ru/blog/mysql/41000.html

 

[Sean]

Посмотрел вопосы. Часто спрашивают про расширение возможностей движка innoDB.
А у меня вопрос зачем поддерживать одновременно несколько движков, каждый из которых имеет свои недостатки?
Может проще сделать один полноценный, включающий достоинства обоих (с меньшим количеством недостатков и полной поддержкой хранимых процедур)?

 

[vavr]

Будет ли реализована работа с командной строкой на тригер?
Идея в том чтоб при изменении в БД запускалось бы внешнее приложение (пхп скрипт, отправка на мыло и тд.).

 

[Aco]

1. Когда появится FULL JOIN? А то приходится жонглировать LEFT/RIGHT JOIN.

2. Когда нормально заработает GROUP BY id DESC? Поясню. GROUP BY группирует схожие записи, выбирая первую строчку из группы забивая на остальные. Из опыта скажу, что есть необходимость, сгрупировав, выводить последнюю из группы. Казалось бы для этого есть GROUP BY id DESC, но GROUP BY id DESC = GROUP BY id ORDER BY id DESC , что всё равно выводит первую строчку из группы и отсортировывает их...
Приходится использовать медленную констукцию:
SELECT id, type, data
FROM table
WHERE id IN (SELECT MAX(id) FROM table GROUP BY type)

3. Что-нибудь делается для ускорения JOIN?

4. Будет ли возможность шифровать БД? Если файлы MySQL сольют, то вытащить оттуда не составляет труда, имхо.

 

[Alexandre]

Будет ли возможность шифровать БД?

снизит скорость, хотя вопрос хороший
нужно сделать жесткую привязку файлов БД к развернутому дистрибутиву
тогда на другом развернутом дистрибутиве нельзя будет восстановить информацию копии файлов БД.

когда будет нативная поддержка XML или более быстрая и полная?

была даже идея написать самому тип энджине XML, пока соображаю как это сделать с точки зрения интерфейса.

 

[pentabion]

GROUP_CONCAT и REPLACE

Не знаю к чему отнести:
1) GROUP_CONCAT - игнорирует упорядочивание
2) REPLACE - например, для строки ",1,3,4,5,5,7" замена ",5," на "," пропустит вторую "5", то есть перебор строки однонаправлен, и не проверяет ранее замененные символы...

ВОПРОС: Это проблема, или было запланировано?

 

[AlexanderR]

Когда в MySQL проявятся вложенные запросы?

 

[Фанат]

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

 

[korchasa]

1. Когда примут патч, который позволяет задавать long_query_time в микросекундах.

2. Планируется ли сделать более умное кэширование запросов? Планируется ли API для управления кэшами?

3. Будет ли тип boolean?

 

[Alexandre]

Когда в MySQL проявятся вложенные запросы?

AlexanderR у тебя какая версия муськи, 3.23 ?

 

[varan]

Автор оригинала: AlexanderR
Когда в MySQL проявятся вложенные запросы?

Эх, жалко я на конфе не буду. Очень хотелось бы услышать ответ на этот вопрос ))

 

[Gorynych]

Вопрос: Планируется ли реализовать оператор INTERSECT?

 

[Gas]

1. планируется ли расширять функционал/синтаксис Stored Routines?
Текущие возможности неконкурентноспособны, а сделаны для галочки.

2. планируется ли сделать некоторые system variables изменяемыми не только на global уровне, но и на уровне session или дополнить схему базы данных, чтоб можно было их менять per database.
fulltext settings, key_buffer_size, init-file, innodb_flush_log_at_trx_commit вообще хотелось per table устанавливать, ну и другие.

[updated]
блин, уже 16 мая

-~{}~ 16.05.08 12:16:

Когда примут патч, который позволяет задавать long_query_time в микросекундах.

приняли

REPLACE - например, для строки ",1,3,4,5,5,7" замена ",5," на "," пропустит вторую "5",

попробуй это сделать php и удивишься что результат будет аналогичным.

 

[svetasmirnova]

Gas
> Текущие возможности неконкурентноспособны, а сделаны для галочки.

А можно обосновать?

 

[Gas]

насчёт галочки наверное погарячился, а насчёт первого - конкурентом mysql, естественно является postgres.
FOR r IN SELECT * FROM foo
тип переменной RECORD
RAISE
EXCEPTION (DECLARE HANDLER в mysql, брррр)
сам синтаксис - наглядный, понятный, смотришь и прямо написать чего-то хочется, в отличие от mysql.

Понятно что у mysql это фича относительно новая и есть ещё куда расти. Вопрос собственно в том и стоит, будет ли Mysql в обозримом будущем развивать функциональность и делать синтаксис логичней или эта задача не приоритетна и в планах стоит где-то далеко ?

p.s. если бы они тупо содрали у pg, думаю, очень многие были бы за

 

[svetasmirnova]

Вопрос понятен, спасибо

 

[Wicked]

почему в mysql нету возможности делать дампы, похожие на родной постгрессовский формат pg_dump -Fc, который автоматически использует такие фишки, как:
* быстрая загрузка записей (используя команду COPY - аналог load data local по скорости)
* сжатие дампа
* несмотря на сжатие: возможность частичного восстановления (только схема, только данные для нескольких таблиц,...) за время, зависящее от объема доставаемой информации, а не от объема всего дампа.

на самом деле есть тулза, которая делает что-то подобное - http://maatkit.sourceforge.net/doc/mk-parallel-dump.html - но у нее свои недостатки.

 

[zerkms]

1) GROUP_CONCAT - игнорирует упорядочивание

у него есть возможность указать свою сортировку, что гораздо логичнее "общей"

 

[MVV]

Просьба к чайникам не задавать тупых вопросов и не портить эту тему. Для этого создайте отдельный топик.

 

[DiMA]

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

INSERT/REPLACE .... VALUES (...), (...), ...

но не просто так, а с применением INSERT ... ON DUPLICATE KEY UPDATE, т.е. примерно так:

INSERT .... VALUES (...), (...), ... ON DUPLICATE KEY UPDATE VALUES (...), (...), ...

-~{}~ 27.09.09 14:20:

ой, мля, тема то прошлогодняя... кто ее поднял?