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

BEGIN TRANSACTION;

таким образом, вы можете откатиться после ошибки.

сначала сделайте резервную копию: это должен быть закон номер 1 системного администрирования в любом случае

EDIT: включение того, что другие сказали, убедитесь, что ваши обновления имеют соответствующие пункты WHERE.

В идеале, изменение живой базы данных никогда не должно происходить (кроме вставок и основного обслуживания). Изменение структуры live DB особенно чревато потенциальной плохой кармой.

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

часто перед обновлением или удалением я пишу эквивалентный выбор.

никогда не выполняйте обновление, если вы не находитесь в BEGIN TRAN t1--не в базе данных dev, не в производстве, нигде. Никогда не запускайте COMMIT TRAN t1 вне комментария-всегда вводите

--COMMIT TRAN t1

и затем выберите инструкцию для ее выполнения. (Очевидно, это относится только к клиентам запросов GUI.) Если вы делаете эти вещи, это станет второй натурой, чтобы сделать их, и вы не потеряете почти никакого времени.

у меня на самом деле есть макрос "update", который печатает это. Я всегда вставляю это чтобы установить обновления. Вы можете сделать аналогичный для удаления и вставки.

begin tran t1
update 
set 
where 
rollback tran t1
--commit tran t1

всегда убедитесь, что ваши обновления и удаления имеют правильное предложение WHERE.

ответить на мой собственный вопрос:

при написании инструкции обновления, напишите его из строя.

1. написать UPDATE [table-name]
2. написать WHERE [conditions]
3. вернитесь и напишите SET [columns-and-values]

выбор строк, которые вы хотите обновить, прежде чем сказать, какие значения вы хотите изменить, намного безопаснее, чем делать это в другом порядке. Это делает его невозможным для update person set email = 'bob@bob.com' чтобы сидеть в окне запроса, готовый к запуску неуместным нажатие клавиши, готовое испортить каждую строку в таблице.

Edit: как говорили другие, напишите WHERE предложение для вашего удаления, прежде чем писать DELETE.

в качестве примера, я создаю SQL, как это

--Update P Set
--Select ID, Name as OldName, 
    Name='Jones'
From Person P
Where ID = 1000

Я выделяю текст от конца до выбора и запускаю этот SQL. Как только я проверю, что он тянет запись, которую я хочу обновить, я нажимаю shift-up, чтобы высветить инструкцию Update и запустить ее.

обратите внимание, что я использовал псевдоним. Я никогда не обновляю имя таблицы explicity. Я всегда использую псевдоним.

Если я делаю это в сочетании с транзакциями и откатом / фиксацией, я действительно, действительно безопасный.

Мой #1 способ быть осторожным с живой базой данных? Не трогай его. :)

резервные копии могут отменить ущерб, который вы наносите базе данных, но вы все еще можете ввести негативные побочные эффекты в течение этого промежутка времени.

независимо от того, насколько прочным вы считаете сценарий, с которым вы работаете, запустите его через цикл тестирования. Даже если" тестовый цикл " означает запуск сценария против вашего собственного экземпляра базы данных, убедитесь, что вы это делаете. Гораздо лучше ввести дефекты на местном поле, чем в производственной среде.

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

еще пара вещей, которые я нашел полезными:

• если используется MySQL, включите безопасная обновления

• если у вас есть DBA, попросите их сделать оно.

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

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

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

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

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

проверьте дважды, зафиксируйте один раз!

резервное копирование или дамп базы данных перед началом.

добавить к тому, что @Вейн сказал, написать WHERE перед именем таблицы в DELETE или UPDATE заявление.

РЕЗЕРВНОЕ КОПИРОВАНИЕ ДАННЫХ. Узнал, что один трудный путь работы с клиентскими базами данных на регулярной основе.

всегда добавляйте предложение using.

мое правило (как разработчик приложения): не трогайте его! Вот для чего нужны обученные БД. Черт, я даже не хочу разрешения прикоснуться к нему. :)

разные цвета для каждой среды: мы настроили наш разработчик PL\SQL (IDE для Oracle), чтобы при входе в производственную БД все окна были ярко-красными. Некоторые из них дошли до назначения другого цвета для dev и test.

убедитесь, что вы указали предложение where при удалении записей.

всегда проверяйте любые запросы за пределами select на данных разработки сначала, чтобы убедиться, что он имеет правильное влияние.

1. если возможно, попросите спариться с кем-нибудь
2. всегда считайте до 3 перед нажатием Enter (если один, так как это приведет в бешенство вашего партнера по паре!)

Если я обновляю базу данных с помощью скрипта, я всегда удостоверяюсь, что поставил точку останова или две в начале моего скрипта, на всякий случай, если я случайно попал в run/execute.

Я добавлю к рекомендациям делать BEGIN TRAN перед вашим обновлением, просто не забудьте на самом деле сделать коммит; вы можете нанести такой же ущерб, если оставите свою незафиксированную транзакцию открытой. Не отвлекайтесь на телефоны, сотрудников, обед и т. д., Когда в середине обновлений или вы обнаружите, что все остальные заблокированы, пока вы не совершите или откат.

Я всегда комментирую любые деструктивные запросы (insert, update, delete, drop, alter) при написании запросов adhoc в Анализаторе запросов. Таким образом, единственный способ запустить их-выделить их, не выбирая закомментированную часть, и нажать F5.

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

1. всегда создавайте резервную копию перед изменением.
2. всегда делайте моды (например. ALTER TABLE) через скрипт.
3. всегда изменять данные (например. Удалить) с помощью хранимой процедуры.

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