Часть 10 из 16
Теперь у нас есть связанные таблицы и понятные правила, но расписание фестиваля меняется: событие заканчивается, а билет получает отметку прохода. Пора разобраться с UPDATE и DELETE — командами, которые меняют данные, а не просто показывают их.
В этой части мы сначала читаем строку, проверяем точный ключ и только потом вносим изменение. Особое внимание уделим условию WHERE: одна забытая строка в запросе может изменить всю таблицу.
Добавляем тестовую продажу
INSERT INTO ticket_sales
(event_id,ticket_code,ticket_type,price,sold_at)
VALUES (1,'FEST00000001','standard',1200.00,'2026-10-20 10:15:00');
Внешний ключ требует существующее событие, UNIQUE не позволит повторить код.
Проверяем перед UPDATE
SELECT sale_id,ticket_code,checked_in_at
FROM ticket_sales WHERE ticket_code='FEST00000001';
Убедитесь, что нашли именно нужную строку. Потом отметьте проход, не перезаписывая уже использованный билет:
UPDATE ticket_sales
SET checked_in_at='2026-10-30 18:02:00'
WHERE ticket_code='FEST00000001' AND checked_in_at IS NULL;
После UPDATE проверьте число изменённых строк и снова выполните SELECT.
Опасность отсутствующего WHERE
UPDATE events SET status='finished' изменит все события. Перед массовой правкой выполните SELECT с тем же WHERE и сделайте копию данных. Удаляйте по первичному ключу только после проверки.
Удалять или архивировать?
Продажу в реальной системе обычно не стирают: её отменяют с историей. DELETE нужен для тестовых данных и только при понимании связей. Далее зададим правила в самой схеме и обсудим индексы.
Читаем число изменённых строк
После UPDATE phpMyAdmin сообщает, сколько строк затронуто. Если ожидалась одна, а изменилось сто, немедленно остановитесь и проверьте условие. В MySQL нередко различаются совпавшие и реально изменившиеся строки, поэтому полезно смотреть также повторный SELECT: какое значение сохранилось?
Используйте максимально точный критерий. Уникальный ticket_code или первичный ключ sale_id предпочтительнее фильтра только по типу билета. Добавочное условие checked_in_at IS NULL работает как защита от повторной отметки: билет, уже прошедший турникет, не будет молча переписан.
UPDATE нескольких полей и проверка перед удалением
SELECT event_id, status
FROM events
WHERE event_id = 2;
UPDATE events
SET status = 'finished',
ends_at = '2026-10-31 20:00:00'
WHERE event_id = 2;
Этот пример изменяет событие с ID 2; сначала убедитесь, что это нужное событие. Для DELETE действует та же дисциплина: выполните SELECT с будущим WHERE, затем удаляйте только после проверки.
Ограничения внешнего ключа могут запретить удаление события, у которого есть продажи — это защита истории, а не ошибка, которую нужно обходить.
В администрировании массовых данных применяют транзакцию и резервную копию. В следующей части добавим правила на уровне схемы и разберём, почему индекс не следует создавать на каждое поле.
Изменения можно сделать проверяемыми
Для исправления сначала покажите ключ и текущие значения:
SELECT event_id, name, status
FROM events
WHERE event_id = 2;
Затем применяйте UPDATE к тому же ключу и проверьте новое значение отдельным SELECT. Такой двухшаговый цикл помогает не спутать ID. В phpMyAdmin сообщения о числе затронутых строк полезны, но повторное чтение подтверждает содержимое.
Осторожно с массовыми командами
Условие вроде WHERE status = 'planned' может выбрать не одно событие, а целую очередь. Если нужно изменить именно одну запись, фильтруйте по первичному или уникальному ключу. Для массовой правки сначала выполните SELECT с тем же условием и при необходимости подсчитайте строки через COUNT(*).
DELETE и UPDATE без WHERE затрагивают всю таблицу. В phpMyAdmin есть кнопки редактирования строки, но они не заменяют понимание SQL: за интерфейсом выполняется такая же команда. В рабочем процессе используйте транзакции и проверенные резервные копии.
Далее закрепим некоторые правила, чтобы сервер отвергал невозможные значения сам.
Проверка перед опасной командой
- Выполните SELECT с тем же WHERE.
- Сверьте первичный ключ и число найденных строк.
- Запустите UPDATE или DELETE только для нужных строк.
- Повторите SELECT и проверьте новое состояние.
Для массовой правки заранее подготовьте копию. Если MySQL отклонил удаление из-за внешнего ключа, сначала решите, что делать с зависимыми данными; не отключайте проверку наугад.
← Предыдущая статья: Нормализация MySQL: проектируем связи без дубликатов
Следующая статья: Ограничения и индексы MySQL: защищаем данные и запросы →
0
21