Для моїх клієнтів я час від часу працюю в їхній базі даних, щоб виправити проблему, яку вони створили для себе, або щоб виправити помилкові дані, які створили помилки мого продукту. Подібно до кореневого доступу Unix, це просто небезпечно. Які уроки я повинен навчитися заздалегідь?
Яку річ No1 ви робите, щоб бути обережними при роботі з реальними даними?
Відповіді:
Три речі, яких я навчився важким шляхом за ці роки ...
По-перше, якщо ви робите оновлення або видаляєте дані в реальному часі, спочатку напишіть запит SELECT із пропозицією WHERE, яку ви будете використовувати. Переконайтесь, що це працює. Переконайтеся, що це правильно. Потім додайте оператор UPDATE / DELETE до відомого робочого речення WHERE.
Ви ніколи не хочете мати
DELETE FROM Customers
сидячи у своєму аналізаторі запитів, чекаючи на те, що ти напишеш речення WHERE ... випадково натиснув "Виконати", і ти щойно вбив таблицю своїх клієнтів. На жаль
Крім того, залежно від вашої платформи, з’ясуйте, як швидко зробити “резервну копію таблиці”. У SQL Server 2005,
SELECT *
INTO CustomerBackup200810032034
FROM Customer
скопіює кожен рядок з усієї таблиці Клієнта в нову таблицю під назвою CustomerBackup200810032034, яку ви зможете видалити після того, як оновите оновлення та переконаєтесь, що все в порядку. Якщо трапиться найгірше, набагато легше відновити відсутні дані з цієї таблиці, ніж спробувати відновити вчорашню резервну копію з диска або стрічки.
Нарешті, будьте обережні, коли каскадні видалення позбавляються від речей, які ви не збиралися видаляти - перед тим, як щось змінювати, перевірте взаємозв'язок таблиць та ключові обмеження.
BEGIN TRANSACTION;
Таким чином ви можете відмовитись після помилки.
Спочатку зробіть резервну копію: це все одно має бути законом номер 1 системного адміністрування
EDIT : враховуючи сказане іншими, переконайтесь, що ваші ОНОВЛЕННЯ мають відповідні пункти WHERE.
В ідеалі, зміна оперативної бази даних ніколи не повинна відбуватися (крім ВСТАВКИ та базового обслуговування). Зміна структури реального БД особливо чревата потенційно поганою кармою.
Внесіть зміни в копію, і коли вас це влаштує, застосуйте виправлення до live.
Часто перед тим, як зробити ОНОВЛЕННЯ або ВИДАЛИТИ, я пишу еквівалентний SELECT.
НІКОЛИ не робіть оновлення, якщо ви не перебуваєте у ПОЧАТКУ TRAN t1 - ні в базі даних розробників, ні у виробництві, ні де-небудь. НІКОЛИ не запускайте COMMIT TRAN t1 поза коментарем - завжди введіть
--COMMIT TRAN t1
а потім виберіть оператор, щоб його запустити. (Очевидно, це стосується лише клієнтів із графічним інтерфейсом.) Якщо ви зробите ці дії, це стане другою природою робити їх, і ви навряд чи втратите час.
Я насправді макрос "оновлення", який вводить це. Я завжди вставляю це, щоб налаштувати оновлення. Ви можете зробити подібний для видалення та вставки.
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 = '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, щоб виділити оператор оновлення та запустити його.
Зауважте, що я використовував псевдонім. Я ніколи не оновлюю чіткість імені таблиці. Я завжди використовую псевдонім.
Якщо я роблю це спільно з транзакціями та відкатом / комітами, я справді дуже справді в безпеці.
Мій спосіб No1 бути обережним із активною базою даних? Не чіпайте його. :)
Резервні копії можуть скасувати шкоду, яку ви завдаєте базі даних, але ви все одно ймовірно матимете негативні побічні ефекти протягом цього періоду часу.
Незалежно від того, наскільки надійним ви вважаєте сценарій, з яким працюєте, запустіть його протягом тестового циклу. Навіть якщо "тестовий цикл" означає запуск сценарію проти власного екземпляра бази даних, переконайтеся, що ви це робите. Набагато краще вносити дефекти на місцевій коробці, ніж виробниче середовище.
Ще кілька речей, які я знайшов корисними:
якщо ви використовуєте MySQL, увімкніть безпечні оновлення
Якщо у вас є DBA, попросіть їх це зробити.
Я виявив, що ці три речі утримали мене від серйозної шкоди.
Ну, це приблизно все, що я зараз можу придумати. Візьміть сміливі уривки, і ви побачите, що для мене No1. ;-)
Якщо ви використовуєте Oracle або іншу базу даних, яка її підтримує, перевірте свої зміни перед тим, як робити COMMIT.
Дані завжди слід розгортати для роботи за допомогою скриптів, які можна репетирувати стільки разів, скільки потрібно, щоб отримати їх прямо на dev. Коли є залежні дані, щоб сценарій працював правильно на dev, сформулюйте його належним чином - ви не зможете уникнути цього кроку, якщо справді хочете бути обережними.
Різні кольори для кожного середовища: ми налаштували наш розробник PL \ SQL (IDE для Oracle) так, щоб при вході в робочу БД усі вікна були яскраво-червоними. Деякі дійшли до того, що призначили інший колір для розробників та тестів.
Обов’язково вкажіть речення where під час видалення записів.
завжди спочатку перевіряйте будь-які запити, крім відбору, щодо даних розробки, щоб переконатися, що вони мають правильний вплив.
Якщо я оновлюю базу даних за допомогою сценарію, я завжди переконуюсь, що ставлю точку зупинки або дві на початку мого сценарію, про всяк випадок, якщо випадково запущу / виконаю.
Я додаю до рекомендацій щодо BEGIN TRAN перед ОНОВЛЕННЯМ, просто не забудьте насправді зробити COMMIT; Ви можете нанести стільки ж збитків, якщо залишити незароблену транзакцію відкритою. Не відволікайтеся на телефони, колеги, обід тощо, коли ви перебуваєте в середині оновлень, інакше ви знайдете, що всі інші заблоковані, доки ви НЕ ВЖИВАТИСЯ або ВІДМОВИТИСЯ.
Я завжди коментую будь-які руйнівні запити (вставляти, оновлювати, видаляти, скидати, змінювати), виписуючи спеціальні запити в Query Analyzer. Таким чином, єдиний спосіб їх запустити - це виділити їх, не виділяючи коментовану частину, та натиснути F5.
Я також вважаю, що це гарна ідея, як уже зазначалося, написати своє твердження where десь із виділенням і переконатись, що ви змінюєте правильні дані.
Створіть користувача лише для читання (або змусіть DBA це зробити) і використовуйте цього користувача лише для перегляду БД. Додайте відповідні дозволи до схеми, щоб ви могли переглядати вміст збережених процедур / переглядів / тригерів / тощо. але не мають можливості їх змінювати.