Во-первых, для этого предназначены таблицы аудита. Если вы знаете, кто удалил все записи, вы можете либо ограничить их права доступа к базе данных, либо работать с ними с точки зрения производительности. Последний человек, который сделал это в моем офисе, в настоящее время находится на испытательном сроке. Если она сделает это снова, ее отпустят. Вы несете ответственность, если у вас есть доступ к производственным данным, и обеспечение того, что вы не причиняете вреда, является одним из них. Это проблема производительности, а также техническая проблема. Вы никогда не найдете способа, чтобы люди не совершали глупых ошибок (база данных не может определить, имели ли вы в виду удаление таблицы a или удаление таблицы a, где id = 100, и большинство людей автоматически получит подтверждение). Вы можете попытаться уменьшить их, только убедившись в том, что люди, выполняющие этот код, несут ответственность, и внедрив политики, помогающие им вспомнить, что делать. Сотрудники, которые ведут себя безответственно с вашими данными о работе (особенно после того, как они получили предупреждение) должны быть уволены.
Другие предложили, что мы делаем, чтобы этого не произошло. Я всегда встраиваю выделение в удаление, которое запускаю из окна запроса, чтобы убедиться, что оно удалит только те записи, которые я намереваюсь. Весь наш производственный код, который изменяет, вставляет или удаляет данные, должен быть включен в транзакцию. Если он запускается вручную, вы не запускаете откат или фиксацию, пока не увидите количество затронутых записей.
Пример удаления со встроенным выбором
delete a
--select a.* from
from table1 a
join table 2 b on a.id = b.id
where b.somefield = 'test'
Но даже эти методы не могут предотвратить все человеческие ошибки. Разработчик, который не понимает данные, может запустить select и все же не понять, что он удаляет слишком много записей. Запуск в транзакции может означать, что у вас есть другие проблемы, когда люди забывают зафиксировать или откатить и заблокировать систему. Или люди могут поместить его в транзакцию и все еще нажимать на фиксацию, не думая так же, как они нажимают «Подтвердить» в окне сообщения, если оно есть. Лучшая профилактика - иметь возможность быстро восстанавливаться после подобных ошибок. Восстановление из таблицы журнала аудита обычно происходит быстрее, чем из резервных копий. Кроме того, у вас есть возможность узнать, кто совершил ошибку и какие записи были затронуты (возможно, вы не удалили всю таблицу, но ваше предложение where было неверным и вы удалили несколько неправильных записей.)
По большей части производственные данные не должны изменяться на лету. Вы должны написать сценарий изменения и сначала проверить его на dev. Затем на Prod все, что вам нужно сделать, это запустить скрипт без изменений, а не выделять и запускать маленькие кусочки по одному. Сейчас в реальном мире это не всегда возможно, так как иногда вы исправляете что-то сломанное только на том продукте, который необходимо исправить сейчас (например, когда никто из ваших клиентов не может войти в систему, потому что важные данные были удалены). В таком случае вы не можете себе позволить воспроизвести проблему сначала на dev, а затем написать исправление. Когда у вас возникают проблемы такого типа, вам может потребоваться исправить непосредственно на prod, и у вас должны быть только dbas или аналитики базы данных, или менеджеры конфигурации, или другие лица, которые обычно отвечают за данные на prod, которые делают исправление, а не разработчик. Разработчики вообще не должны иметь доступа к продукту.