раскрыть ветку (65)
А потому что перед delete или update всегда нужно делать select, если ты не великий профи :)
Хотя в серьёзных случаях (не только в sql) я всегда вводил ещё одну подстраховку - перед финальным нажатием на enter отходил покурить. Несколько раз было, когда приходила дельная мысль в это время.
раскрыть ветку (22)
Селектануть
Подумать
Прогнать раз запрос, обернутым в begin tran .. rollback tran. Если количество affected rows устраивает, то поменять rollback на commit и ещё раз.
Пользуюсь всеми тремя способами)
Плюс у нас на всех таблицах висят триггеры на модификацию данных, пишущие в журнальные таблички, если что, можно вытащить из них
раскрыть ветку (6)
раскрыть ветку (5)
раскрыть ветку (4)
Пока открыта(не закрыта транзакция) обращение к этой таблице невозможно = все зависнет наглухо.
раскрыть ветку (2)
Спасибо, полезно узнать такое) я субд изучал очень поверхностно, нужно было программу с табличкой подружить
перед финальным нажатием на enter отходил покурить
Хорошая практика. Тоже так делаю.
Разумеется подстраховываюсь бекапами данных (самое простое - копии таблиц), но зачастую восстанавливать их гораздо муторнее, чем просто сделать хорошо. Так вот во время "покурить" действительно приходят умные мысли. Иногда даже отказаться от этой затеи и пойти вообще другим путём.
раскрыть ветку (10)
Не, все подстраховки, все подготовки, бэкапы и т.п. это само-собой. Иногда и обдумывать можешь неделю перед этим, но я говорю именно про ту самую последнюю секунду, когда вроде готово всё и нужно "нажать на enter". Смешно, но реально именно эти пять минут пару раз помогали.
раскрыть ветку (1)
Гы, помню в 4 года назад месяц курил, выдумывая одну фишку.
Короче структура БД готова, логика написана, осталось придумать, как сделать один механизм, но чтобы он был универсальным. Иначе придётся писать 100500 обработок под конкретный случай.
Жопой чую, что можно, но как - хз. Ходил курил, думал. Возвращался - смотрел комбинации данных, не выходит - опять думал. Звонил юзерам, спрашивал как и с чем работают (будут работать) опять не выходит.
В итоге родил. Ну дальше дело техники - день написать и тестировать, вылизывать, и т.д.
Представляю, на кого я был похож в течении этого месяца: ходит, курит, нихуя не делает. Хотя голова разрывалась.
Самая лучшая подстаховка - это разделение на тех, кто имеет доступ к проду и тех, кто пишет тот же sql запрос. Естественно, что те, кто пишут его должны проверить в том числе и на препроде, где лежит копия бд прода.
В этом случае прод не снести, а остальное все ломать не страшно
раскрыть ветку (3)
Всё верно. Но когда архитектор, разработчик, администратор, аналитик и уборщица в одном лице, есть нюансы :)
раскрыть ветку (2)
Разумеется подстраховываюсь бекапами данных (самое простое - копии таблиц)
Ну да, особенно когда удаляешь данные из-за того, что места на диске кончается. ,:)
раскрыть ветку (3)
Когда место на диске кончается на сервере БД - удалять данные прям замечательная идея! :)
раскрыть ветку (2)
раскрыть ветку (2)
Когда я бросил курить привычка осталась. На работе выхожу в коридор или на лестницу БЦ в такой ситуации, дома просто на кухню к окну :)
раскрыть ветку (1)
О, а вот это интересно 😀
Мне ликбеза ради, а почему тут шайтан машина все делетнула? Поясните, плиз, неразумной мне🤔
Каг бэ, сердцем я чую, что косяк в where, а разум чот не догоняет...
раскрыть ветку (24)
Грубо говоря, скобки не поставили в запросе, и запрос выглядит либо (id=23) либо (22) <без привязки к id>
Синтаксис таков, что 22 всегда true, поэтому аффектит всё из drby
По-хорошему, надо было как-то так:
WHERE ID IN(22, 23)
раскрыть ветку (23)
То есть, получается, что выражение where 23 даст на выходе true?
Какой интересный зверек этот mysql...
раскрыть ветку (21)
В других языках также) if (23) в с++, например, тоже будет true, собственно, с любым числом будет true, кроме 0)
раскрыть ветку (19)
раскрыть ветку (12)
Т.е. весь говнокод, который написан и непонятно как-то "работает", перестанет работать и сразу выявятся места этого говнокода? Плохо разве?
раскрыть ветку (10)
Если "говнокод" работает на соседней АЭС, к примеру, то...
Понятно, что я утрирую, но так эти дела не делаются.
раскрыть ветку (9)
Конечно не делаются, ведь помимо прода есть еще всякие стейджинги, препроды, тестирование, тестирование, тестирование, бекапы, пробы на бекапах, автоматизированное тестирование, автоматизированное и ручное код ревью и много других вещей, описаывающих хороший, годный процесс деплоя/наката обновлений на продукционную среду.
Удаление говнокода (техдолга) - нормальный рабочий процесс, такой же, как и добавление новый фич, заменa/удаление старых, обновление БД, инфраструктуры и прочей требухи.
Я уверен, что на таких критических важных структурах, как АЭС, процессы еще более вдумчивые и защищенные. И уж тем более, иметь WHERE 42 в прямой связи с каким-нибудь ядрёным модулем — уже причина нахуй закрыть АЭС, вместо того чтобы кричать мантру "работает - не трогай".
Поэтому нет, говнокод надо исправлять, а такие фразочки как "перестанет работать много написанного" в итоге приводят к тому, что продукт нужно будет выбросить на мусорку и делать новый с нуля.
раскрыть ветку (8)
А кроме этого ещё есть куча легаси кода, причём хорошо, если этот код ты можешь редактировать, а это не либа какая нибудь от устройства, производитель которого не только исчез давно как предприятие, но и все, кто принимал участие в разработке уже умерли давно от старости )
раскрыть ветку (2)
Если он легаси и за ним никто не следил, но от него зависит критическая инфра - то это такая же проблема, как и какой-нибудь критически важный насос, за которым тоже никто не следил. И в этом случае тоже слепо накатывать новую СУБД ни один ебанавт не будет, ну разве что недоджун какой-нибудь.
Поэтому этот аргумент вообще нихрена не аргумент.
раскрыть ветку (1)
И уж тем более, иметь WHERE 42 в прямой связи с каким-нибудь ядрёным модулем — уже причина нахуй закрыть АЭС
Гм. Вы из страны эльфов пишете?
раскрыть ветку (4)
раскрыть ветку (3)
раскрыть ветку (2)
Откуда ж мне знать, я не работаю на АЭС. Но я бы закрывал, если говнокод может привести к большим потерям, чем его исправление.
раскрыть ветку (1)
Проблема в том, что когда создавали АЭС строчка говнокодом не являлась.
Это нормальная практика, что с течением времени инструменты развиваются и стандарт, актуальный несколько лет назад, сейчас является устаревшим и потенциально опасным.
Весь софт не АЭС явно проходил всю долгую процедуру тестирования и является безопасным, не смотря на то, что там используются уже старые и небезопасные методы.
А переписывать части на новый подход менее безопасно, чем не трогать то, что работает.
Чего она вдруг бредовая? Работает точно по спецификации. То, что пришёл новичок не читавший спеку и начал всё, чего не понял, обзывать говнокодом - не повод переписывать проверенное стабильное решение.
раскрыть ветку (3)
бредовая потому, что неочевидная. спецификации сперва пишутся, а потом переписываются. я не новичок, и вполне понял принцип работы, и тем не менее называю его говнокодом. а переписывать стабильное решение - не эквивалентно написанию нестабильного. если руки не из жопы конечно.
раскрыть ветку (2)
С тем же успехом можно потребовать переписать все проекты на Си, потому что там используется нумерация массивов с нуля, а вам кажется более правильным нумеровать по традиции Паскаля с единицы. Холивар и не более.
Обзывать говнокодом стабильно работающий механизм, на котором работают миллионы проектов может либо очень авторитетный разработчик, либо неграмотный выскочка
раскрыть ветку (1)
это именно фича, которую именно специально спроектировали. а бредовая она потому, что нарочно смешивает разные типы данных (bool и integers), что ни к чему, кроме возможности ошибиться, особо привести не может. и всё, видимо, в дань традиции сишных языков, которые к sql вообще никак не относятся.
ещё комментарии
раскрыть ветку (1)
Begin tran
Запрос
--commit
--rollback
Если оставить незакоммиченную транзакцию надолго, серверу будет очень плохо. Проверено. Поэтому если всë ок, коммитим, если "что-то пошло не так", выполняем rollback.
Это в MS SQL
раскрыть ветку (10)
раскрыть ветку (9)
WAT?
https://dev.mysql.com/doc/refman/8.0/en/innodb-autocommit-co...
In InnoDB, all user activity occurs inside a transaction.
Это тоже транзакция.
Небось автокоммит включён? Тогда ССЗБ.
раскрыть ветку (8)
раскрыть ветку (7)
раскрыть ветку (6)
раскрыть ветку (5)
Ну видимо возможность делать косяки важнее. В оракле например нет автокоммита по умолчанию, и это правильно.
раскрыть ветку (3)
Меньше ошибок не станет) однострочные запросы начнут выглядеть так
delete from users where 1; commit;
раздражение пользователей, приложений, где-то orm не поддерживает.
Потому что никто так не делает, экзотику не оценят. Поэтому не дают доступ в БД на запись кому попало. А если че-то ебнули, то есть инструменты по восстановлению даже одиночных записей из бэкапа, бинлоги. Я не большой мастер Mysql, но держал на такие случаи реплики БД с отставанием репликации на несколько минут/часов.
раскрыть ветку (2)
IT-юмор
7.5K постов53.3K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору