Ответы на вопросы разработчикам MySQL на PHPConf 2008 с т.з. пользователя PostgreSQL
Исходная тема с вопросами была опубликована в форуме, к которому не у всех есть доступ
• Часто спрашивают про расширение возможностей движка innoDB. А у меня вопрос зачем поддерживать одновременно несколько движков, каждый из которых имеет свои недостатки? Может проще сделать один полноценный, включающий достоинства обоих (с меньшим количеством недостатков и полной поддержкой хранимых процедур)?
В PostgreSQL движок один, он одновременно умеет и внешние ключи, и полнотекстовый поиск, бгыгыгы.
• Будет ли реализована работа с командной строкой на тригер? Идея в том чтоб при изменении в БД запускалось бы внешнее приложение (пхп скрипт, отправка на мыло и тд.).
Можно использовать untrusted процедурные языки, они позволяют обращаться к объектам вне базы. По очевидным причинам их использование разрешено только суперпользователям.
• Когда появится FULL JOIN? А то приходится жонглировать LEFT/RIGHT JOIN.
Уже есть.
• Когда нормально заработает 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)
Насколько я понял вопрос, может помочь
конструкция DISTINCT ON.
• Что-нибудь делается для ускорения JOIN?
Да, используется cost-based оптимизатор вместо rule-based, см. мой доклад на phpconf 2008.
• Будет ли возможность шифровать БД? Если файлы MySQL сольют, то вытащить оттуда не составляет труда, имхо.
Вряд ли будет, используйте шифрование на уровне ФС. К тому же если пароль будет храниться рядом, то его "сольют" вместе с файлами, а если не будет, то его придётся каждый раз вводить при перезапуске.
• Когда будет нативная поддержка XML или более быстрая и полная?
Типа такой?
http://www.postgresql.org/docs/8.3/interactive/datatype-xml.html
• Не знаю к чему отнести:
1) GROUP_CONCAT - игнорирует упорядочивание
2) REPLACE - например, для строки ",1,3,4,5,5,7" замена ",5," на "," пропустит вторую "5", то есть перебор строки однонаправлен, и не проверяет ранее замененные символы...
ВОПРОС: Это проблема, или было запланировано?
• Когда в MySQL проявятся вложенные запросы?
Пропустим...
• Когда появится поддержка BLOB?
Давно есть:
http://www.postgresql.org/docs/8.3/interactive/largeobjects.html
• Когда примут патч, который позволяет задавать long_query_time в микросекундах.
Если устроят миллисекунды, то параметр log_min_duration_statement задаётся именно в них.
• Планируется ли сделать более умное кэширование запросов? Планируется ли API для управления кэшами?
• Возможно ли реализовать кэширование запросов, в которых происходит обращение к UDF, при условии что она имеет характеристику DETERMINISTIC? под UDF имел в виду Stored Function.
Кэширование не планируется, кэш на уровне базы данных в основном нужен для того, чтобы хорошо выглядеть в пузомерках. Чоткие пацаны кэшируют на уровне приложения.
Давно есть.
• Будет ли реализовано каскадное обновление внутри одной таблицы?
Не понял вопроса, честно гря. Никто не мешает повесить FOREIGN KEY на ту же самую таблицу или триггер склепать. Понятное дело, что если зациклится, то сами себе злые бакланы, будет ROLLBACK.
• Когда MySQL начнет нормально оптимизировать и отрабатывать запросы типа
select t1.value, t2.value from table1 as t1
left join table2 t2 on (t1.id = t2.id)
where t1.value like '%value%' OR t2.value like '%value%'
а так же во всех остальных случаях когда по OR ищется в 2 и более связанных таблицах?
Этот запрос нормально не оптимизировать, тут обязательно будут 2 последовательных просмотра.
• Когда появится такой тип данных, как массивы?
Уже есть.
• Когда сделают возможным использование php для написания сторед процедур и ф-ций?
PL/PHP:
https://projects.commandprompt.com/public/plphp
• Будет ли возможность использовать вложенные запросы? А то workaround с derived неэстетично.
• Планируется ли ускорять работу с VIEW? Сейчас выполнение запросов напрямую без использования представлений во много раз быстрее, чем с их использованием.
Оптимизатор во многих случаях может сложные запросы привести в "плоский" вид, ещё раз сошлюсь на свой доклад.
• А всё ж таки почему второй BEGIN выполняет на самом деле COMMIT; BEGIN; ? Эта "недокументированная фича" на мой взгляд крайне не логична, ибо ежели уж не поддерживаются вложенные транзакции, то почему бы просто не игнорировать второй BEGIN; ?
Код:
phpconf=# begin;
BEGIN
phpconf=# delete from articles;
DELETE 239
phpconf=# begin;
WARNING: there is already a transaction in progress
BEGIN
phpconf=# rollback;
ROLLBACK
phpconf=# select count(*) from articles;
count
-------
239
(1 запись)
• Будет ли поддержка каскадного удаления ?
Уже есть.
• Появится ли поддержка ролей (либо групп пользователей) в обозримом будущем?
Уже есть.
• Будет ли возможность шифровать БД? Если файлы MySQL сольют, то вытащить оттуда не составляет труда, имхо. Имеется ввиду вытащить информацию из файлов БД
Дубль.
• Будет ли возможно использовать RETURN в хранимых процедурах? Иногда код со множеством IF-THEN-ELSE выглядит слишком громоздко.
Давно можно, RETURN NEXT видимо нужен.
