Pytanie:
Jak uniknąć ryzyka omyłkowego usunięcia danych ze środowiska produkcyjnego bez kopii zapasowych?
Jude Niroshan
2015-04-16 11:43:51 UTC
view on stackexchange narkive permalink

Jestem młodszym programistą, który wciąż nie jest pewien swojej roli. Mam do czynienia z bardzo wrażliwymi, niemożliwymi do odzyskania danymi w naszym środowisku produkcyjnym. Duża część mojej pracy obejmuje różne zadania w naszym środowisku na żywo. Jeśli omyłkowo usunąłem jakieś cenne dane, co mam zrobić? Ja ręcznie (używając skryptów SQL) przenoszę rzeczy w bazie danych tu i tam.

Czy powinienem prosić moich seniorów, aby nie powierzali mi tego rodzaju ryzykownych zadań? To tak jakby powiedzieć, że w ogóle nie radzę sobie z żadną ryzykowną pracą. Chcę im powiedzieć, żeby nie przeciążali mnie ryzykowną pracą. Jakie jest najlepsze podejście, aby o to zadać?

Nie ma możliwości przywrócenia danych z kopii zapasowych, ponieważ dane, które obsługuję, często się zmieniają. Właściwie jeszcze niczego przypadkowo nie usunąłem. To hipotetyczna sytuacja.

Skoro uważasz się za niedoświadczonego, czy jesteś pewien, że te zmiany danych są nieodwracalne? Może powinieneś zapytać, co zrobić na wszelki wypadek.
Komentarze nie służą do rozszerzonej dyskusji; ta rozmowa została [przeniesiona do czatu] (http://chat.stackexchange.com/rooms/22931/discussion-on-question-by-jude-niroshan-if-i-mistakenly-delete-some-data-from- pr).
czy nie możesz zaimplementować przynajmniej podstawowych skryptów kopii zapasowych
Rozwiązaniem dla wysoce dynamicznych danych nie jest „brak kopii zapasowych”, ale raczej dublowanie / replikacja danych w czasie rzeczywistym, jako dodatek do okresowych kopii zapasowych.
@LindaJeanne tak. Mamy kilka baz danych slave i mam do czynienia z bazą danych master.
Dziewięć odpowiedzi:
#1
+113
user8036
2015-04-16 12:25:03 UTC
view on stackexchange narkive permalink

Jedną rzeczą, którą możesz zrobić teraz , jest sprawdzenie, jakie zabezpieczenia są na miejscu. To pokazuje branie odpowiedzialności. Czy Twoja firma ma ostatnie kopie zapasowe na wypadek, gdyby coś poszło nie tak? Czy możesz tworzyć kopie zapasowe ad hoc przed zmianą krytycznych części? Czy pracujesz na systemach testowych i czy masz dobrą procedurę wdrażania zmian w systemach na żywo? Itd.

Jeśli tych zabezpieczeń brakuje, poproś o ich udostępnienie.

Przy okazji jestem zaskoczony, że mówisz, że pracujesz z danymi nieodwracalnymi . Jeśli tak jest w rzeczywistości, jest to czerwona flaga dla całej firmy. Nic (cóż, tak mało jak to możliwe) nie powinno być „nieodwracalne”.

„poproś o udostępnienie ich”? Jestem w 90% pewien, że odpowiedź brzmi „nie”. Firmy, które wiedzą, że zabezpieczenia awaryjne są potrzebne, zainstalowały je już, zanim młodszy programista o nie poprosi. Ci, którzy ich nie mają, to ci, którzy wierzą, że „Nie potrzebuję śmierdzących kopii zapasowych, Twoim obowiązkiem jest być nieomylnym, a strach, że strzelę ci w tyłek, jeśli cokolwiek się stanie, zapewni, że nie popełnisz błędów zawsze". Nie zmieniają swoich sposobów tylko dlatego, że poprosił o to nowy młodszy programista. Tak więc w rzeczywistości ta odpowiedź to ślepa uliczka. \
@rumtscho Żądanie powinno zostać wystosowane mimo to, z prawdopodobieństwem 0,2%, że będzie miał szefa, który rzeczywiście rozumie, jakie to ważne, i aby można było udokumentować żądanie, aby w przyszłości uniknąć wskazywania palcem.
@rumtscho A może nikt nigdy nie wpadł na ten pomysł komuś, kto mógłby wydać pieniądze na rozwiązanie… W przeszłości otrzymałem źle utrzymane zbiory danych i odniosłem duży sukces, prosząc o aktualizację infrastruktury, aby lepiej nimi zarządzać.
Potrzebujesz kopii zapasowych, nie tylko w celu ochrony danych klientów, ale także po to, aby praca była racjonalnie wydajna. Na przykład, jeśli wiesz, że nie ma kopii zapasowej, prawdopodobnie będziesz pracować w sposób, który jest zbyt ostrożny, np. ponowne sprawdzanie każdego polecenia na komputerze lokalnym przy użyciu danych testowych, spowalniając nawet rutynowe zadania. Jeśli chcesz zrobić poprawkę na działającej maszynie, zrób to w efektywny sposób, ale przygotuj plan wycofywania na wypadek, gdyby poprawka nieoczekiwanie zepsuła coś innego.
#2
+36
PointlessSpike
2015-04-16 17:29:29 UTC
view on stackexchange narkive permalink

Nigdy, przenigdy nie powinieneś modyfikować niemożliwych do odzyskania danych produkcyjnych.

Naprawdę nie mogę tego wystarczająco podkreślić. Powinieneś być gotów zająć w tej sprawie stanowisko. Gdybym to był ja, wystąpiłbym z dwoma żądaniami.

  1. Częste tworzenie kopii zapasowych (najlepiej więcej niż jeden zestaw) wykonywane automatycznie. Częstotliwość zależy od wrażliwości danych, ale powiedziałbym, że przynajmniej raz dziennie. Czy klient będzie skłonny zaakceptować utratę danych z tygodnia, jeśli coś pójdzie nie tak?

  2. Że to nie Ty to robisz. To jest właściwie ważniejsze, ale pierwsze powinno tak być. Ty, programista, nie powinieneś bawić się danymi na żywo. Nie znam wielkości Twojej firmy, ale pracuję w pięćdziesięcioosobowej firmie i programiści są informowani, jeśli wchodzą w interakcję z działającym systemem. Jeśli masz dział pomocy technicznej, to ich praca i nawet w przypadku kopii zapasowych powinieneś czuć się nieswojo, dotykając danych na żywo. Prace rozwojowe powinny być zawsze wykonywane tylko w systemie programistycznym. Jeśli trzeba coś zrobić z działającym systemem, każesz im to zrobić, nawet kosztem wydajności. Jeśli potrzebujesz, dostarcz dobrze przetestowany skrypt. Generalnie jednak wszelkie zmiany powinny nastąpić tylko wtedy, gdy wszyscy są świadomi, że system może się zepsuć, więc klienci muszą być świadomi tej możliwości. Jeśli jako programista musisz dotykać danych na żywo, nie rób tego bez kopii zapasowych, nawet czegoś małego.

Te rzeczy są dość podstawowe. Zawsze należy brać pod uwagę potencjalne skutki błędów i robić wszystko, co możliwe, aby zminimalizować to ryzyko. Może się to wydawać zbyt ostrożne, ale jeśli nie podejmiesz środków ostrożności, osobiste konsekwencje będą znacznie większe, jeśli coś pójdzie nie tak.

Żaden deweloper nie powinien nigdy uruchamiać skryptów w produkcyjnej bazie danych. Nie powinni nawet mieć do tego praw. Tylko administrator DBA lub członek zespołu Build powinien to robić lub w najgorszym przypadku tylko menedżerowie. Firma, która umożliwia młodszym programistom dostęp do produkcji, zasługuje na to, co otrzymują.
@HLGEM Zgoda, niestety rzeczywistość jest taka, że ​​bardzo wiele firm ma programistów, dobrych, którzy są praktycznie zmuszani do robienia tego rodzaju ryzykownych bzdur przez cały czas. „Hej Jim! Kim właśnie przesyła nowe kontakty do produkcji za pośrednictwem portalu. Dział prawny chce, abyśmy zmienili ich źródło, aby księgowość mogła je odpowiednio obciążyć. Jest ich 60 000, och, a księgowość musi być w stanie rozpocząć fakturowanie w ciągu godziny, więc my nie masz czasu na kopiowanie danych do bazy danych deweloperów, zrób to! liczę na Ciebie mistrzu! ” * facepalm * (szkoda, że ​​to żart)
@HLGEM: Nie każda firma jest wystarczająco duża, aby _posiadać_ „DBA” lub „Budowanie zespołu”. I na pewno nigdy nie spotkałem menedżera, który miałby pierwszą wskazówkę, jak zrobić coś takiego.
Zawsze powinien być ktoś, kto zajmuje się obsługą aktualnie działających systemów i korzystających z nich klientów. To właśnie robi te rzeczy.
@PointlessSpike Czasami jedna osoba pełni dwie role. Może programista to także personel pomocniczy. Byłem zatrudniony jako inżynier oprogramowania, ale w ramach tej samej roli zajmowałem się również budowaniem, testowaniem i obsługą klienta. Pracujesz z personelem, który masz.
@Lightning Byłem tam - w mikro-startupach ludzie muszą nosić wiele kapeluszy. Ale nawet tam jedynymi osobami, które powinny mieć dostęp do aktualizacji serwera produkcyjnego, są osoby, które dokładnie wiedzą, co robią, które wiedzą, że należy wcześniej przećwiczyć nawet najmniejszą zmianę w środowisku testowym i którym firma powierza to zrobić. Najlepiej tak mało, jak to możliwe.
W takim razie kopie zapasowe i ktoś, kto wie, jak to wszystko zrobić. Jeśli masz kogoś wykonującego wiele takich ról, prawdopodobnie powinien mieć doświadczenie.
Jeśli druga osoba, którą zatrudniasz, nie jest specjalistą od baz danych, gdy masz aplikację skoncentrowaną na danych, już masz kłopoty. Jeśli masz produkcyjną bazę danych i nie masz dba, masz kłopoty. Nie ma znaczenia wielkość firmy, ważne jest, aby zatrudnić odpowiednich ludzi do zadań, które należy wykonać. Jeśli masz więcej niż jednego programistę aplikacji, powinieneś już wynająć dba. Jeśli masz tylko jednego programistę aplikacji, nie powinieneś zatrudniać kogoś młodszego. Jeśli wykonałeś niewłaściwą pracę, nie zatrudniając odpowiednich specjalności, jesteś zbyt winny, gdy coś nie dzieje się prawidłowo.
@HLGEM Przykro mi, ale naleganie, aby żaden „programista” nie miał dostępu do produktu, jest nonsensem. Czasami programista (choć prawdopodobnie nie młodszy) jest najbardziej wykwalifikowaną osobą do wykonania zadania. I tak ślepe poleganie na jakimś silosie cię nie uratuje. Sposobem na obniżenie ryzyka jest dobra strategia odzyskiwania danych i dokładne testy. Nie ma znaczenia, czy robi to programista, administrator czy inżynier sys; potrzebujesz tylko kogoś kompetentnego do wykonania zadania.
#3
+17
rdab
2015-04-16 13:34:39 UTC
view on stackexchange narkive permalink

Przed wykonaniem jakiejkolwiek pracy, która może spowodować utratę danych, upewnij się, że masz plan wycofywania. Zwykle oznacza to wykonanie ręcznej kopii zapasowej bazy danych przed uruchomieniem jakiegokolwiek skryptu sql, który zmienia dane. Jest to część Twojej odpowiedzialności jako osoby wykonującej pracę.

Następnym razem, gdy zostaniesz poproszony o wykonanie takiej pracy, poinformuj swojego przełożonego, że zamierzasz wykonać kopię zapasową bezpośrednio przed wykonaniem zmiana.

Uwaga boczna: Zawsze przydatne jest dołączanie skryptów sql do BEGIN TRANSACTION. ROLLBACK TRANSACTION po raz pierwszy uruchamiasz je na danych produkcyjnych. Spowoduje to wykonanie skryptu i wyświetlenie danych wyjściowych bez faktycznego stosowania zmian. To daje dobre wskazanie, ile rekordów zostanie zmienionych i czy wystąpią jakieś błędy.

Tak, pomyśl o „Co poszło nie tak?” * zanim * pójdzie źle. Jednak rada dotycząca „ROZPOCZĘCIA TRANSAKCJI ...” wydaje mi się nieco niebezpieczna: nawet jeśli zostanie zastosowana, zapytanie nadal może wyłączyć system produkcyjny, na przykład powodując zbyt duże obciążenie. Te rzeczy za bardzo zależą od konkretnej sytuacji, nie ma uniwersalnego, „bezpiecznego” sposobu uruchamiania rzeczy w systemie produkcyjnym.
@sleske, jeśli miałoby spowodować zbyt duże obciążenie i zlikwidować serwer, zrobiłoby to z lub bez transakcji rozpoczęcia / wycofywania, więc nie widzę wad korzystania z niego w porównaniu do samego wykonania skryptu
Tak, oczywiście, i przepraszam, nie to miałem na myśli. Miałem na myśli: nawet z ROLLBACK na końcu, uruchomienie skryptu może * nadal * powodować problemy. Oczywiście dodanie ROLLBACK jest znacznie lepsze niż od razu bieganie bez niego. Chciałem tylko ostrzec ludzi, że to wciąż może być niebezpieczne.
Nie zapomnij sprawdzić, czy możesz przywrócić (lub przynajmniej odzyskać dane) z kopii zapasowej, zanim rzeczywiście będziesz musiał to zrobić!
#4
+9
CodeGnome
2015-04-17 22:21:11 UTC
view on stackexchange narkive permalink

Ryzyko organizacyjne i indywidualne badanie due diligence

Co mam zrobić, jeśli omyłkowo usunę jakieś cenne dane? Ręcznie (za pomocą skryptów SQL) przenoszę rzeczy w bazie danych tu i tam.

Kwestia, czy firma postępuje właściwie, wprowadzając zmiany w danych produkcyjnych, które nie mają Kopie zapasowe to tak naprawdę decyzja biznesowa, która wykracza poza twoją płatność. Chociaż z pewnością możesz zalecić, aby tego nie robili ze względu na ryzyko, byłbym bardzo zdziwiony, gdyby nie byli jeszcze świadomi zagrożeń i uznali je za akceptowalne ryzyko dla firmy w porównaniu z kosztami zrobienia czegoś systemowego. .

Ze swojej strony powinieneś wykonać własne pełne lub częściowe kopie zapasowe przed wprowadzeniem zmian. Chociaż tworzenie kopii zapasowej całego systemu może być niepraktyczne, z pewnością możesz zrzucić rekordy, które planujesz zmienić, lub pliki konfiguracyjne, które planujesz zmodyfikować, aby móc je przywrócić w przypadku błędu.

To nie ochroni przed katastrofalnymi awariami (np. upuszczeniem całej bazy danych, na przykład), ale z pewnością zapewni, że jeśli wprowadzisz zmiany do rekordu 12345, możesz przywrócić ten rekord po wprowadzeniu zmian, jeśli okaże się, że zmiany były nieprawidłowe.

Pamiętaj tylko, że chociaż jesteś profesjonalistą odpowiedzialnym za zwrócenie uwagi kierownictwa na ryzyko i łagodzenie go tak dobrze, jak jesteś w stanie we własnym pracy, zespół zarządzający Twojej organizacji faktycznie ponosi 100% ryzyka biznesowego. Jeśli zrobiłeś swoją należytą staranność najlepiej jak potrafiłeś, wszelkie pozostałe ryzyko spoczywa na organizacji, a nie na tobie.

W razie wypadku ...

W przypadku, gdy coś się stanie pójdzie nie tak, Twoim zawodowym obowiązkiem jest natychmiastowe poinformowanie o tym kogoś z władz. Powinieneś poinformować ich, co się stało, jakie dane zostały utracone, co (jeśli w ogóle) jesteś w stanie odzyskać i zaoferować pomoc we wszelkich dodatkowych działaniach, które mogą być potrzebne.

Tego rodzaju błędy nie powinny być zakryte. Jednakże, chociaż powinieneś przyznać się do wszelkich popełnionych błędów lub błędów, pamiętaj, że odpowiedzialność za posiadanie systemu bez odpowiednich zabezpieczeń jest ryzykiem, które należy do organizacji, a nie do Ciebie. Weź odpowiedzialność za swój udział w wypadku, ale nie miej winy za awarię systemu bez odpowiednich zabezpieczeń.

Istnieje duża różnica między przejęciem odpowiedzialności a wzięciem winy. Upewnij się, że akceptujesz tylko to pierwsze, a nie drugie, chyba że naprawdę zrobiłeś coś niedbałego.

#5
+5
Matthieu M.
2015-04-17 17:42:23 UTC
view on stackexchange narkive permalink

W jednym są właściwie dwa pytania:

  • kto powinien być odpowiedzialny za zmiany w danych produkcyjnych?
  • jak najlepiej wprowadzić te zmiany?

Pozwól, że odniosę się do nich osobno.


Kto powinien być odpowiedzialny za zmiany w danych produkcyjnych?

Żadnej pojedynczej osoby.

Jaki jest sposób przeprowadzania zmiany; zmiana w produkcji (lub jakimkolwiek wrażliwym systemie) powinna zostać sprawdzona przez przynajmniej inną (znającą się na rzeczy) osobę i zatwierdzona przez jakiegoś kierownika.

Jest to praca zespołowa i przestrzeganie łańcucha odpowiedzialności. W tym momencie nie ma znaczenia, czy popełnisz błąd:

  1. Zostanie zastosowany tylko wtedy, gdy ktoś inny przejrzał go (i nie zauważył problemu)
  2. Zostanie zastosowana tylko wtedy, gdy jakiś menedżer ją zatwierdzi (i wziął na siebie odpowiedzialność)

Jeśli żaden menedżer nie jest skłonny wziąć odpowiedzialności za zmianę, nie wykonuj jej.

Jeśli ludzie spierają się o wrażliwość zmiany na czas, powiedz im, że nigdy nie należy mylić bycia szybkim z pośpiechem . Właściwie opowiadałbym się za dodatkową ostrożnością w nagłych przypadkach (na przykład inny recenzent), szczególnie dlatego, że ciśnienie zwiększa ryzyko błędów. O wiele szybciej jest mieć rację za pierwszym razem niż zepsuć wszystko, posprzątać bałagan i w końcu dokonać zmiany.


Jak najlepiej wprowadzić te zmiany?

Idealnie :

  • kopia zapasowa jest dostępna i jest procedura przywracania
  • zmiana jest wykonywana za pomocą skryptu, któremu towarzyszy sprawdzony (*) skrypt awaryjny.

Niestety, warunki nie zawsze są idealne.

Kopie zapasowe są dobre, ale w środowisku na żywo, w którym dane zmieniają się co sekundę, po prostu nie jest możliwe zapewnienie ich dokładnej aktualności; Kopie zapasowe mogą być używane tylko w przypadku ogromnego błędu i po zaakceptowaniu, że najnowsze zmiany zostaną utracone. Dlatego nie mogę wystarczająco nalegać na skrypty zmian i sprawdzenie, czy skrypt awaryjny działa zgodnie z przeznaczeniem.

Niektórych zmian nie można cofnąć. Na przykład podczas usuwania kolumny danych w tej kolumnie nie można przywrócić w przypadku problemu. Te zmiany należy wykonać dwuetapowo:

  • w pierwszym kroku wyłącz dostęp do fragmentu danych, który zostanie usunięty, bez faktycznego usuwania go; w przypadku kolumny zmień jej nazwę na przykład. Ten krok można cofnąć.
  • następnie, gdy zostanie ocenione, że zmiana była ważna (minęło kilka dni lub tygodni bez problemów), wykonaj nienadającą się do upadku zmianę w skrypcie przeznaczonym do jednego celu

(*) Aby zweryfikować skrypt awaryjny, musisz uruchomić go na kopii prawdziwej bazy danych, a następnie zastosować skrypt awaryjny i sprawdzić, czy dane wróciły do ​​normy.

(*) Widziałem sugestię zrobienia zmiany w transakcji; jest to niewystarczające (co jeśli zdasz sobie sprawę z błędu po zatwierdzeniu?), podatne na rywalizację (blokujesz wszystkie zmodyfikowane wiersze do momentu zatwierdzenia) i nie zawsze możliwe (zbyt duży zestaw zmian / ryzyko zakleszczeń). Mimo to, jeśli to możliwe, używaj transakcji w skrypcie, ponieważ połowiczne zmiany są trudniejsze do cofnięcia.

#6
+3
HLGEM
2015-04-16 18:55:47 UTC
view on stackexchange narkive permalink

Jeśli utkniesz w tym systemie (i poważnie bym to odrzucił, ponieważ jest to skrajnie ryzykowne i kiepska praktyka), oto co bym zrobił.

Najpierw utwórz kopię zapasową tabeli dla dane, na które masz zamiar mieć wpływ (mamy bazę danych do jednorazowego użytku). W oczekiwaniu na jeden rozmiar danych możesz chcieć utworzyć indeks na ten temat)

Gdy masz już kopię zapasową tabeli, umieść wszystko w transakcji. Następnie, gdy wykonujesz zapytanie, aby wpłynąć na łączenie danych w utworzonej tabeli kopii zapasowej.

Po uruchomieniu uruchamiaj po jednym kroku i zanotuj, ile rekordów znajduje się w tabeli pomostowej, jeśli dane dotyczą w zapytaniu funkcjonalnym nie odpowiada liczbie rekordów w tabeli, będziesz chciał wycofać zmiany, a następnie dowiedzieć się, dlaczego.

Takie podejście zapewnia również największą elastyczność przywracania, jeśli zmiana była zła, ponieważ łatwiej i ogólnie szybciej zaktualizować jedną tabelę do starych wartości niż przywrócić całą bazę danych. A jeśli tylko kilka rekordów zostało błędnie zmienionych, masz możliwość przywrócenia starych wartości tylko w tych rekordach.

Alternatywą dla tego wszystkiego jest posiadanie tabel audytu, które rejestrują wszystkie zmiany. Jednak jest mało prawdopodobne, abyś je miał, jeśli deweloperzy pracują bezpośrednio na produkcji. Osobiście nigdy nie rozważałbym posiadania bazy danych bez przeprowadzania audytu, ponieważ wspaniale jest naprawiać błędy, które pochodzą z interfejsu użytkownika, a także importować dane i skrypty akcji ad hoc, które są uruchamiane w bazie danych, w tym w przypadku złośliwej zmiany danych. ale pracuję w środowisku regulacyjnym, w którym jest to wymagane.

Dodane później Zapomniałem wspomnieć, niech ktoś inny sprawdzi kod, zanim to zrobisz.

#7
+2
Edwin Lambregts
2015-04-16 12:25:11 UTC
view on stackexchange narkive permalink

Jestem pewien, że wiesz o tym, ale i tak zwrócę uwagę na oczywiste: przetestuj, przetestuj i zrób więcej testów. Jest tak wiele rzeczy, które mogą się nie udać, jeśli nie przeprowadzisz odpowiednich testów, a jednym z wielu jest przypadkowe usunięcie danych. Naśladując środowisko produkcyjne rzeczywistymi danymi, możesz testować w środowisku, które jest realistyczne i ograniczać liczbę błędów i błędów do minimum.

Pamiętaj, że nawet po wielu godzinach intensywnych testów błędy nie i stanie się . Jeśli tak, zgłoś się do swojego przełożonego / kierownika i wyjaśnij. Jeśli w jakikolwiek sposób twój kod zamknie połączenie z bazą danych, miliony rekordów, które powinny zostać wstawione, znikną (ale to tylko przykład). Jeśli zauważysz błąd lub podejrzewasz błąd: poinformuj innych o tym .

#8
+2
Tim
2015-04-16 23:24:35 UTC
view on stackexchange narkive permalink

Jeśli musisz zrobić WSZYSTKO w systemie produkcyjnym, zrób to w transakcji. (Lub pozwól administratorowi to zrobić, jeśli go masz)

Wiele lat temu widziałem przerażoną minę mojego szefa, który przeprowadzał „prostą” aktualizację produkcyjnej bazy danych, bez WHERE .

Gdyby wykorzystał transakcję, mógłby wydać ROLLBACK i oszczędzić sobie spanikowanej nocy odzyskiwania danych z kopii zapasowej do nadal działającego systemu produkcyjnego. (Cofnięcie zajęłoby dwie sekundy, a nie cztery godziny ...)

(To brzmi jak kreskówka Scotta Adamsa, ale tak, faktycznie to widziałem ...)

Mój szef regularnie opowiada nam o tym, jak upuścił całą bazę danych podczas szkolenia w dziale. Przez chwilę był spanikowany, że zrobił to na produkcji, ale miał szczęście, że zrobił to na naszej bazie danych serwera testowego.
#9
+1
Doug Krugman
2015-04-18 00:40:00 UTC
view on stackexchange narkive permalink

Innym prostym sposobem uniknięcia katastrofalnych błędów jest przyzwyczajenie do dodawania instrukcji limitu (np. limit 1; jeśli zmieniasz tylko jeden rekord).

Więc jeśli modyfikujesz coś takiego jak tabela użytkowników, nawet jeśli zapomnisz klauzuli WHERE, jak zrobił to szef @tima, zepsujesz tylko jeden rekord użytkownika, a nie każdy rekord użytkownika.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...