Часть 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: за интерфейсом выполняется такая же команда. В рабочем процессе используйте транзакции и проверенные резервные копии.

Далее закрепим некоторые правила, чтобы сервер отвергал невозможные значения сам.

Проверка перед опасной командой

  1. Выполните SELECT с тем же WHERE.
  2. Сверьте первичный ключ и число найденных строк.
  3. Запустите UPDATE или DELETE только для нужных строк.
  4. Повторите SELECT и проверьте новое состояние.

Для массовой правки заранее подготовьте копию. Если MySQL отклонил удаление из-за внешнего ключа, сначала решите, что делать с зависимыми данными; не отключайте проверку наугад.

← Предыдущая статья: Нормализация MySQL: проектируем связи без дубликатов

Следующая статья: Ограничения и индексы MySQL: защищаем данные и запросы →