← All posts tagged MySQL

alex0b

Ну как так? При truncate внешние ключи учитываются, а тригер на удаление на очищаемой таблице не вызывается. Для каких целей это нужно? Одноногие наркоманы пилят ноги другим: что inserted_id, что affected_rows, что транзакции, что блокировки. Какой нахер кластер, тут бы acid осилить.
Пересмотрел свои записи с тегом *mysql — много плакал.

alex0b

Пишу: truncate table ...; А оно мне: Cannot delete or update a parent row: a foreign key constraint fails. Казалось бы, идиотизм? Ан-нет, стоит учесть еще: "Triggers currently are not activated by foreign key actions" чтобы почувствовать весь вкус победы над здравым смыслом.

alex0b

настолько идиотскую реализацию транзакционной модели нельзя называть транзакционной субд. innodb ваще проказа. сжечь! ок. никому больше не буду желать мучений. буду слушать Coldplay

alex0b

"для колонок, не указанных в group-by и для которых не указана агрегирующая функция, возращаемое значение недетерменировано, в том смысле, что выбирается любое из группы" (с) dev.mysql.com

очень интересно, какому это дибилу пришло в голову насочинять эту фичу ? пишут, что для пущего перфоманса. я даже не про то, что это нестандартный sql — это просто не-пришей-козе-боян какой-то! кому на хрен нужно непонятно какое значение? значит использование сей фичи имеет смысл только когда запросо-писатель гарантированно знает, что каждое уникальное значение этого полюшка в результсете соответвует только одному значению последнего поля указанного в group-by. Таким образом, поцаны съэкономили на каждое такое левое поле, по одному групировочному циклу, каждый из которых содержал бы всего 1 шаг. молодцы. это теперь не мускуль, а ракета просто, епт!

теперь возьмем упыря-быдлокдера 1 шт, который знать не знает что такое группировка и как ей пользоваться, и явно по недосмотру богов, поручим ему написать мега-софт. он дурак и запилит кривой запрос, причем на myisam таблицах (но это отдельная история). поцаны умудрятся сей мега-софт поставить на продакшен и он несколько лет будет там крутиться — все ровно. но как только нагрузка превысит терпение пользователя, вынужденого из-за блокировок по несколько минут ждать результата, и поцаны переконвертят таблицы в innodb — их ожидает знатный фейл: начинает выбираться другое значение для негрупированной колонки. да-да-да, запрос был изначально кривой, и то что сначала приходило нужное значение — чистое совпадение. но самый смех начинает разбирать, когда обнаруживаешь в этом запросе having левая колонка is null и смотришь на результсет.. да.. там не только null, но и цифорки разные.

вот и вопрос нахрена нужна бесполезная фича, которая разрешает писать кривые запросы всяким ушлепкам?

p.s. Андрюша, если ты это когда-нибудь, скотина, это прочтешь, знай — я первый в очереди раздавить твои яица в чеснокодавке!