упс. моя ошибка: я имел ввиду каскадное обновление, а не удаление.
"InnoDB does not support cascaded update to the SAME table. It could lead to an infinite loop in the current implementation."
1) будет ли возможность использовать вложенные запросы? А то workaround с derived неэстетично.
2) а всёж таки почему второй BEGIN выполняет на самом деле COMMIT; BEGIN; ? Эта "недокументированная фича" на мой взгляд крайне не логична, ибо ежели уж не поддерживаются вложенные транзакции, то почему бы просто не игнорировать второй BEGIN; ?
А Вы пробовали делать это хоть на каких-нибудь разумных объёмах? Просто mysql обрабатывает конструкции типа where id in (select id from blablabla) крайне неразумно.
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 сольют, то вытащить оттуда не составляет труда, имхо.
храните файлы на криптованном разделе (gbde, geli и т.д). на проихводительность не жалуйтесь.
в том, что кто-то когда-либо придумает способ шифрования, скрывающий данные но сохраняющий их связность (т.е. индексы), я сомневаюсь - это явно противоречивые требования просто с точки зрения банальной эрудиции=)
Ну про производительность понятно. Поэтому хотелось что бы шифровались только указанные базыданных. Если углубить процесс шифрование в самые недры апи, то проблем со связность не будет, имхо, из опыта
И ещё вопрос: планируется ли ускорять работу с VIEW? Сейчас выполнение запросов напрямую без использования представлений во много раз быстрее чем с их использованием
1. Будет ли возможно использовать RETURN в хранимых процедурах? Иногда код со множеством IF-THEN-ELSE выглядит слишком громоздко.
2. Возможно ли реализовать кэширование запросов, в которых происходит обращение к UDF, при условии что она имеет характеристику DETERMINISTIC?
Хотелось бы увидеть лучшей способ поиска по тексту чем тот фултекст что есть сейчас.
И систему плагинов чтоб Sphinx, например, можно было б более удобно установить.
В 2009 году мы еще более жестко отфильтровываем доклады и допускаем на конференцию только самое ценное и самое важное. Мы ценим время участников конференции, поэтому конференция по прежнему будет проходить в течении двух дней.
День первый – WebArchitect WorkShop Day 8 октября (чт)
Это день полностью состоящий из мастер-классов. Их прочитают признанные гуру. Каждый мастер-класс могут посетить не более 30 человек. На данный момент планируется 3 потока по 6 часов. Каждый мастер-класс длительностью от 1,5 до 6 часов.
День второй – PHPCONF 2009 9 октября (пт)
Пополните ваши знания! Что нового произошло за 1,5 года? Какие методики разработки стали общепринятыми в профессиональной среде? Как их внедрить малой кровью? Как повысить эффективность вашей работы и работы вашей команды в разы?
P.S. Как всегда приедут непосредственный авторы PHP, MySQL, ZendFramework.
P.S.S. Программа будет опубликована после 25 августа 2009 года.
Вопросы авторам MySQL на PHPConf 2008 29-30мая в Москве