- 1
- 2
- 3
- 4
- 5
delete
from liaison
where
type = 'UsersGroup' and
`group` = 'static_' || (select id from usergroup where name = :grp)-
SQL / Говнокод #13032
−165
Час назад вынес этим запросом все связи между группами и юзерами в боевой базе ;)
P.S. Почему в mysql все дерьмо, работающее совсем не так, как оно работает почти во всех остальных СУБД, включено по умолчанию?Запостил:
bormand,
22 Мая 2013
Follow us!
delete from l
from liaison l inner join usergroup u
on l.group = 'static_' || CAST(u.id as char)
where
type = 'UsersGroup' and u.name = :grp
Простите, не очень силен в мускуле с типами.
Навскидку еще postgres, sqlite, firebird.
MSSQL Breaks the standard by using the '+' operator instead of '||'.
Does not automatically cast operands to compatible types. If an operand is NULL, then the result is NULL.
MySQL Badly breaks the standard by redefining || to mean OR.
Offers instead a function, CONCAT(string, string), which accepts two or more arguments.
Automatically casts values into types which can be concatenated. If an operand is NULL, then the result is NULL.
У них там явно своя атмосфера.
И вообще ручные правки боевых баз - зло.
И напоследок старая истина - любой программист хотя бы раз в жизни запускал update/delete без where.
Любые прямые модифицирующие запросы - зло. Правильно разработать пусть даже для одноразового действия соответствующий функционал (скажем, бизнес-операцию), отладить и использовать только так. Никаких редакторов с прямым выполнением.
В моей практике бывали случаи, когда где-то погроммист из-за копипасты забыл сменить id, а таблицу сменил, отчего удалилось совсем не то. Да тысячи их.
Самый прикол в том, что этот код как раз был в функции, которая выполняла операцию "удаление юзера". Я же не настолько проникся духом пхп, чтобы вызывать запросы и исполнять бинарники прямо из главной функции...
Так что мой фейл совсем не в прямом использовании запросов, а в том, что я отлаживался на боевом сервере ;)
Золотые слова...
Просто, как всегда, сложились обстоятельства - торопился, хотел быстрее накодить спартанскую но удобную админку, толком не знал диалект mysql, тестовый сервак от этой системы давно заюзали под другие нужды, а развертывать новый было влом... Тем более под рукой был свежий бекап, да и таблички эти кроме меня все равно никто никогда не правил.
P.S. На самом деле пользователи даже ничего не заметили, т.к. эти таблички читаются только при логине.
P.P.S. Но согласен, отлаживаться на боевой базе это большой риск, и показатель нуба, коим я и являюсь ;)
Ничего, бывает, просто Луна сегодня не в той фазе
Одно дело когда диалект просто отличается от стандарта (ну функций там добавили, операторов новых, какие-то дополнительные кейворды). Другое - когда авторы СУБД намеренно нарушают стандарты, внося свои бессмысленные и беспощадные "фичи". Вспомните, к примеру, что mysql делает, если не все поля лежат в group by и групповых функциях... а теперь назовите мне еще хотя бы одну базу, у которой есть такое поведение.
> Специалисты с мозолями на жопе
> совершенно не умеют работать молотком (хотя бы иногда)
Окай, не буду принимать это как личное оскорбление. Доля правды тут есть. Но только вот очень часто (где-то в 80% случаев) "работать молотком и думать" = "терять время впустую", примерно как драить плац зубной щеткой, или копать котлован совочком.
Вы естественно никогда ошибок не допускаете, и всегда полностью читаете ман по всем функциям и операторам, которые вы используете в своей работе?
Да, нет такой СУБД (из топ 10), которая бы 100% соответствовала стандарту, но мускуль чаще всего разрывает все шаблоны.
Так что борманд не зря поднимает волну негодования.
I have not increased nor diminished the measure,
I have not diminished the palm,
I have not encroached upon fields,
I have not added to the balance weights,
I have not tempered with the plumb bob of the balance.
Это они так в Древнем Египте после смерти перед Ма'aт оправдывались за несоблюдение стандартов. Кто не соблюдал - того в рай не пускали.