Какой ваш # 1 способ быть осторожным с живой базой данных?

Question

Для моего клиента я иногда работаю в его действующей базе данных, чтобы исправить проблему, которую он создал для себя, или чтобы исправить неверные данные, которые создали ошибки моего продукта. Как и в случае с root-доступом в Unix, это просто опасно. Какие уроки я должен выучить раньше времени?

Что вы # 1 делаете, чтобы быть осторожным при работе с живыми данными?

Answer 1

• Никто не хочет резервного копирования, но все плачут о восстановлении
• Создайте свою БД со ссылками на внешний ключ, потому что вы должны:
• сделать для вас как можно более сложным обновление / удаление данных и разрушение структурной целостности / чего-то еще этим
• Если возможно, запустите систему, в которой вы должны зафиксировать изменения, прежде чем окончательно сохранить их (т.е. деактивировать автокоммит при восстановлении БД)
• Постарайтесь определить классы вашей проблемы, чтобы вы могли понять, как ее исправить без проблем
• Получить процедуру воспроизведения резервных копий в базе данных, всегда иметь под рукой вторую базу данных на тестовом сервере, чтобы вы могли просто работать над этим
• Потому что помните: Если что-то не получается, вам нужно снова и снова работать как можно быстрее

Ну, вот и все, о чем я могу думать сейчас. Возьмите смелые отрывки, и вы увидите, что для меня # 1. ; -) * 1 021 *

Answer 2

1. Проверьте, перепроверьте и еще раз проверьте все записи, которые обновляются. Даже если вы думаете, что делаете простое обновление в одну колонку, рано или поздно вам не хватит кофе и вы забудете предложение «где», обнуляя всю таблицу.

Несколько других вещей, которые я нашел полезными:

• при использовании MySQL включите Безопасные обновления

• Если у вас есть администратор базы данных, попросите его сделать это.

Я обнаружил, что эти 3 вещи не позволяют мне причинить серьезный вред.

Answer 3

Если вы используете Oracle или другую базу данных, которая поддерживает его, проверьте изменения перед выполнением COMMIT.

Answer 4

Проверка дважды, фиксация один раз!

Answer 5

Данные всегда должны быть развернуты для работы с помощью сценариев, которые можно репетировать столько раз, сколько требуется для правильной настройки dev. Когда есть зависимые данные для правильной работы скрипта на dev, подготовьте его соответствующим образом - вы не можете уйти с этим шагом, если действительно хотите быть осторожным.

Answer 6

Может быть, стоит подумать о том, чтобы вообще не использовать удаление или удаление. Или, может быть, уменьшите пользовательские разрешения, чтобы только специальный пользователь БД мог удалять / удалять вещи.

Answer 7

Сделайте резервную копию или выгрузите базу данных перед запуском.

Answer 8

Чтобы добавить к сказанному @ Уэйну , напишите свой WHERE перед именем таблицы в операторе DELETE или UPDATE.

Answer 9

СОЗДАЙТЕ СВОИ ДАННЫЕ. Узнал, что один сложный способ работы с базами данных клиентов на регулярной основе.

Answer 10

Всегда добавлять условие использования.