Что Ваш № 1 путь состоит в том, чтобы быть осторожным с живой базой данных?

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

1. Всегда создают резервную копию перед изменением.
2. Всегда делают модификации (например, ALTER TABLE) с помощью сценария.
3. Всегда изменяют данные (например, УДАЛИТЕ) с помощью хранимой процедуры.

Я всегда комментирую любые разрушительные запросы (вставьте, обновите, удалите, отбросьте, изменитесь) при выписывании специальных запросов в Query Analyzer. Тем путем единственный способ выполнить их, состоит в том, чтобы выделить их, не выбирая прокомментированную часть, и нажать F5.

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

Я добавлю к рекомендациям выполнения, НАЧИНАЮТ TRAN перед Вашим ОБНОВЛЕНИЕМ, просто не забывайте на самом деле делать ФИКСАЦИЮ; можно нанести такой же ущерб при отъезде незафиксированной транзакции открытой. Не становитесь отвлеченными телефонами, коллегами, ланч и т.д., когда посреди обновлений или Вы найдете, что все остальные заблокированы вплоть до Вас ФИКСАЦИЯ или ОТКАТ.

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

BEGIN TRANSACTION;

Тот путь можно откатывать после ошибки.

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

РЕДАКТИРОВАНИЕ : слияние, что сказали другие, удостоверяется, что Ваши ОБНОВЛЕНИЯ имеют соответствующие операторы Where.

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

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

Часто, прежде чем я делаю ОБНОВЛЕНИЕ или УДАЛЯЮ, я пишу эквивалентный ВЫБОР.

НИКОГДА не делайте обновление, если Вы не находитесь в НАЧАТЬ TRAN t1 - не в dev базе данных, не в производстве, не нигде. НИКОГДА не выполните TRAN t1 ФИКСАЦИИ вне комментария - всегда тип

--COMMIT TRAN t1

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

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

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' находиться в Вашем окне запроса, готовом быть выполненным неуместным нажатием клавиши, готовым испортить каждую строку в таблице.

Редактирование: Как другие сказали, запишите 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. Проверка, перепроверьте и проверьте снова любой statment, который делает обновления. Даже если Вы будете думать, что просто делаете простое обновление отдельного столбца, рано или поздно Вы не будете иметь достаточного количества кофе и забудете 'где' пункт, уничтожая целую таблицу.

Пара других вещей я нашел полезными:

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

• , Если у Вас есть DBA, попросите, чтобы они сделали это.

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

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

ну, это обо всем, о чем я могу думать теперь. Возьмите полужирные проходы, и Вы видите то, что является № 1 для меня.;-)

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

Если Вы используете Oracle или другую базу данных, которая поддерживает ее, проверьте свои изменения прежде, чем сделать ФИКСАЦИЮ.

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

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

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

Для прибавления к какой сказанный Wayne запишите Ваш WHERE перед именем таблицы в DELETE или UPDATE оператор.

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

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

Мое правило (как разработчик приложения): не касайтесь его! Это - то, для чего обученные DBAs. Heck, я даже не хочу разрешение коснуться его.:)

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

Удостоверьтесь, что Вы определяете где пункт при удалении записей.

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

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