Для моего клиента я иногда работаю в своей реальной базе данных, чтобы исправить проблему, которую они создали для себя, или для исправления плохих данных, которые создавали мои ошибки продукта. Подобно доступу к корневой системе Unix, это просто опасно. Какие уроки я должен изучить заранее?
Что вы делаете, чтобы быть осторожным при работе с живыми данными?
Три вещи, которые я усвоил на протяжении многих лет...
Сначала, если вы делаете обновления или удаляете данные в реальном времени, сначала напишите запрос SELECT с предложением WHERE, которое вы будете использовать. Убедитесь, что он работает. Удостоверьтесь, что это правильно. Затем добавьте инструкцию UPDATE/DELETE в известное рабочее предложение WHERE.
Вы никогда не захотите иметь
DELETE FROM Customers
сидит в вашем анализаторе запросов, ожидая, когда вы напишете предложение WHERE... случайно нажмите "выполнить", и вы только что убили таблицу Customer. К сожалению.
Кроме того, в зависимости от вашей платформы, узнайте, как быстро выполнить резервное копирование таблицы. В SQL Server 2005
SELECT *
INTO CustomerBackup200810032034
FROM Customer
скопирует каждую строку из всей таблицы Customer в новую таблицу CustomerBackup200810032034, которую вы можете удалить, как только вы сделали свои обновления, и убедитесь, что все в порядке. Если произойдет худшее, намного легче восстановить отсутствующие данные из этой таблицы, чем попытаться восстановить резервную копию прошлой ночи с диска или ленты.
Наконец, будьте осторожны при удалении каскадов, избавляясь от ненужных вам вещей - проверяйте отношения и ограничения ключевых слов перед изменением.
BEGIN TRANSACTION;
Таким образом, вы можете откатиться после ошибки.
Сделайте резервную копию сначала: это должен быть закон с номером 1 sysadmining в любом случае
РЕДАКТИРОВАТЬ: включив то, что говорили другие, убедитесь, что ваши ОБНОВЛЕНИЯ имеют соответствующие предложения WHERE.
В идеале изменение реальной базы данных никогда не должно происходить (кроме INSERT и базового обслуживания). Изменение живой структуры БД особенно чревато потенциальной плохой кармой.
Внесите свои изменения в копию, и когда вы будете удовлетворены, примените исправление к жизни.
Зачастую перед выполнением UPDATE или DELETE я пишу эквивалентный SELECT.
НИКОГДА не выполняйте обновление, если вы не находитесь в BEGIN TRAN t1 - не в базе данных dev, а не в производстве, а не где-либо. НИКОГДА не запускайте COMMIT TRAN t1 вне комментария - всегда введите
--COMMIT TRAN t1
а затем выберите оператор для его запуска. (Очевидно, это относится только к клиентам запросов GUI.) Если вы сделаете это, для них станет второй натурой, и вы вряд ли потеряете время.
На самом деле у меня есть макрос "update", который его набирает. Я всегда вставляю это, чтобы настроить свои обновления. Вы можете создать аналогичный файл для удаления и вставки.
begin tran t1
update
set
where
rollback tran t1
--commit tran t1
Всегда убедитесь, что ваши UPDATE и DELETE имеют правильное предложение WHERE.
Чтобы ответить на мой собственный вопрос:
При написании инструкции обновления выпишите ее не по порядку.
UPDATE [table-name]WHERE [conditions]SET [columns-and-values]Выбор строк, которые вы хотите обновить, прежде чем говорить, какие значения вы хотите изменить, гораздо безопаснее, чем делать это в другом порядке. Это делает невозможным размещение update person set email = '[email protected]' в окне запроса, готовое к запуску неуместным нажатием клавиши, готовое испортить каждую строку в таблице.
Изменить: как говорили другие, напишите предложение WHERE для ваших удалений, прежде чем писать DELETE.
В качестве примера я создаю SQL, подобный этому
--Update P Set
--Select ID, Name as OldName,
Name='Jones'
From Person P
Where ID = 1000
Я выделяю текст с конца до выбора и запуска SQL. Как только я проверю, что он вытаскивает запись, которую я хочу обновить, я нажимаю shift-up, чтобы загорелся оператор Update и запускал его.
Обратите внимание, что я использовал псевдоним. Я никогда не обновляю объяснение имени таблицы. Я всегда использую псевдоним.
Если я делаю это в сочетании с транзакциями и откатом/фиксациями, я действительно, действительно безопасен.
Мой # 1 способ быть осторожным с живой базой данных? Не трогайте его.:)
Резервные копии могут отменить повреждение, которое вы нанесете на базу данных, но вы все еще можете ввести отрицательные побочные эффекты в течение этого промежутка времени.
Независимо от того, насколько вы уверены, что вы работаете с script, выполните его через тестовый цикл. Даже если "тестовый цикл" означает запуск script против вашего собственного экземпляра базы данных, убедитесь, что вы это сделали. Намного лучше ввести дефекты в локальный ящик, чем в производственную среду.
Несколько других вещей, которые я нашел полезными:
если вы используете MySQL, включите Безопасные обновления
Если у вас есть администратор базы данных, попросите их сделать это.
Я обнаружил, что эти 3 вещи не дали мне серьезного ущерба.
Хорошо, это обо всем, о чем я могу думать сейчас. Возьмите смелые отрывки, и вы видите, что № 1 для меня.; -)
Может считаться, что вы не используете никаких удалений или капель вообще. Или, возможно, уменьшить права пользователя, чтобы только специальный пользователь БД мог удалить/удалить вещи.
Если вы используете Oracle или другую базу данных, которая его поддерживает, проверьте свои изменения перед выполнением COMMIT.
Данные всегда должны быть развернуты для работы через скрипты, которые можно репетировать столько раз, сколько требуется, чтобы получить их прямо на dev. Когда зависимые данные для script будут корректно работать на dev, выполните его соответствующим образом - вы не сможете избежать этого шага, если вы действительно хотите быть осторожным.
Проверить дважды, зафиксировать один раз!
Сохраните резервную копию базы данных перед запуском.
Чтобы добавить к тому, что @Уэйн, напишите WHERE перед именем таблицы в инструкции DELETE или UPDATE.
НАЗАД ВАШИХ ДАННЫХ. Узнал, что трудно работать с базами данных клиентов на регулярной основе.
Всегда добавляйте предложение use.
Мое правило (как разработчик приложения): не трогайте его! Это то, чему обучены администраторы баз данных. Черт возьми, я даже не хочу разрешения трогать его.:)
Различные цвета для среды: мы создали наш PL\SQL-разработчик (IDE для Oracle), чтобы при входе в производственную БД все окна были ярко-красными. Некоторые дошли до назначения другого цвета для dev и теста.
Убедитесь, что вы указываете предложение where при удалении записей.
всегда проверяйте любые запросы за пределами выбора данных разработки, чтобы убедиться, что они имеют правильное воздействие.
Если я обновляю базу данных с помощью script, я всегда убеждаюсь, что поставил точку останова или две в начале моего script, на всякий случай, когда я случайно попал в run/execute.
Я добавлю к рекомендациям делать BEGIN TRAN перед вашим ОБНОВЛЕНИЕМ, просто не забудьте на самом деле выполнить COMMIT; вы можете нанести столько же урона, если оставите незафиксированную транзакцию открытой. Не отвлекайтесь на телефоны, сотрудники, обед и т.д., Когда посередине обновлений, или вы обнаружите, что все остальные заблокированы до тех пор, пока вы не COMMIT или ROLLBACK.
Я всегда комментирую любые деструктивные запросы (вставлять, обновлять, удалять, удалять, изменять) при написании adhoc-запросов в Query Analyzer. Таким образом, единственный способ их запуска - выделить их, не выбирая прокомментированную часть и нажать F5.
Я также думаю, что это хорошая идея, как уже упоминалось, написать сначала инструкцию, с выбором, и убедиться, что вы изменяете правильные данные.
Создайте пользователя только для чтения (или получите DBA для этого) и используйте его только для просмотра базы данных. Добавьте соответствующие разрешения для схемы, чтобы вы могли просматривать содержимое хранимых процедур/представлений/триггеров/и т.д. но не имеют возможности их изменять.