Baza danych: aby usunąć lub nie usuwać rekordów

Myślę, że nie tylko ja się nad tym zastanawiam. Co zazwyczaj ćwiczysz w zakresie zachowania bazy danych? Czy wolisz fizycznie usunąć rekord z bazy danych? A może lepiej jest po prostu oflagować rekord flagą „usunięty” lub kolumną logiczną, aby wskazać, że rekord jest aktywny lub nieaktywny?

Z pewnością zależy to od faktycznej zawartości Twojej bazy danych. Jeśli używasz go do przechowywania informacji o sesji, to na wszelki wypadek wyczyść go natychmiast po wygaśnięciu sesji (lub zamknięciu), nie chcesz, aby te śmieci leżały wokół. Ponieważ tak naprawdę nie można go ponownie wykorzystać do żadnych praktycznych celów.

Zasadniczo, o co musisz sobie zadać, czy może być konieczne przywrócenie tych informacji? Podobnie jak usunięte pytania w SO, zdecydowanie powinny być oznaczone jako „usunięte”, ponieważ aktywnie zezwalamy na przywrócenie. Mamy również możliwość wyświetlenia go, aby wybrać użytkowników, bez większej dodatkowej pracy.

Jeśli nie aktywnie starasz się w pełni przywrócić danych, ale nadal chcesz je zachować do monitorowania (lub w podobnych celach). Sugerowałbym, abyś wymyślił (w miarę możliwości oczywiście) schemat agregacji i odrzucił go do innej tabeli. Dzięki temu Twoja tabela podstawowa będzie czysta od „usuniętych” danych, a tabela pomocnicza będzie zoptymalizowana do celów monitorowania (lub cokolwiek miałeś na myśli).

Aby uzyskać dane czasowe, zobacz: http://talentedmonkeys.wordpress.com/2010/05/15/temporal-data-in-a-relational-database/

Zalety używania flagi usuwania:

1. Możesz odzyskać dane później, jeśli będziesz ich potrzebować,
2. Operacja usuwania (aktualizacja flagi) jest prawdopodobnie szybsza niż jej usunięcie

Wady używania flagi usuwania:

1. Bardzo łatwo jest przeoczyć AND DeletedFlag = 'N'jakieś miejsce w swoim SQL
2. Wolniej, aby baza danych znalazła interesujące Cię wiersze wśród wszystkich bzdur
3. Ostatecznie prawdopodobnie i tak będziesz chciał go naprawdę usunąć (zakładając, że Twój system się powiódł. A co z tym, że ten rekord ma 10 lat i został „usunięty” 4 minuty po pierwotnym utworzeniu)
4. Może to uniemożliwić użycie naturalnego klucza. Możesz mieć jeden lub więcej usuniętych wierszy z kluczem naturalnym i prawdziwym wierszem, który chce użyć tego samego klucza naturalnego.
5. Mogą istnieć powody prawne / zgodności, dla których zamierzasz faktycznie usunąć dane.

Jako uzupełnienie wszystkich postów ...

Jeśli jednak planujesz oznaczyć rekord, dobrze jest rozważyć zrobienie widoku dla aktywnych rekordów. To uchroni Cię przed napisaniem lub zapomnieniem flagi w zapytaniu SQL. Możesz również rozważyć widok dla nieaktywnych rekordów, jeśli uważasz, że również służą one celowi.

Cieszę się, że znalazłem ten wątek. Ja też się zastanawiałem, co ludzie myślą o tym problemie. Zaimplementowałem opcję „oznaczona jako usunięta” od około 15 lat w wielu systemach. Za każdym razem, gdy użytkownik dzwonił, aby powiedzieć, że coś zostało przypadkowo usunięte, z pewnością znacznie łatwiej było oznaczyć to jako nieusunięte, niż odtworzyć lub przywrócić z kopii zapasowej.

Używamy postgresql i Ruby na railsach, wygląda na to, że moglibyśmy to zrobić na 1 z dwóch sposobów, zmodyfikować railsy lub dodać wyzwalacz ondelete i zamiast tego wykonuje funkcję pl / pgsql, aby oznaczyć jako usunięte. Skłaniam się ku temu drugiemu.

Jeśli chodzi o wyniki wydajności, interesujące będzie zobaczyć wyniki EXPLAIN-ANALYZE na dużych tabelach do kilku usuniętych elementów, a także wielu usuniętych elementów.

W systemach używanych z biegiem czasu, które odkryłem, nowi użytkownicy mają tendencję do wykonywania głupich rzeczy, takich jak przypadkowe usuwanie rzeczy. Więc kiedy ludzie są nowi na stanowisku, mają wszystkie prawa dostępu osoby na tym stanowisku, z wyjątkiem braku doświadczenia. Przypadkowe usunięcie czegoś i możliwość szybkiego przywrócenia sprawi, że wszyscy szybko wrócą do pracy.

Ale jak ktoś powiedział, czasami z jakiegoś powodu możesz potrzebować tego konkretnego klucza z powrotem, w tym momencie musiałbyś go naprawdę usunąć, a następnie ponownie utworzyć rekordy (po przywróceniu go i zmodyfikowaniu rekordu).

Istnieją również kwestie prawne, jeśli chodzi o dane osobowe. Myślę, że to w dużej mierze zależy od tego, gdzie jesteś (lub gdzie jest baza danych) i jakie są warunki użytkowania.

W niektórych przypadkach ludzie mogą poprosić o usunięcie z systemu, w którym to przypadku konieczne jest trwałe usunięcie (lub przynajmniej usunięcie wszystkich danych osobowych).

Skonsultowałbym się z działem prawnym przed przyjęciem strategii, jeśli w grę wchodzą dane osobowe.

Oznaczam je jako usunięte i tak naprawdę nie usuwam. Jednak od czasu do czasu usuwam wszystkie śmieci i archiwizuję je, więc nie zabija to wydajności.

Jeśli obawiasz się, że „uśpione” rekordy spowalniają dostęp do bazy danych, możesz chcieć przenieść te wiersze do innej tabeli działającej jako tabela „archiwum”.

W przypadku danych wprowadzonych / zarządzanych przez użytkownika użyłem metody flag, którą opisałeś, i dałem użytkownikowi interfejs „opróżnij kosz”, aby faktycznie usunąć elementy, jeśli zdecyduje się to zrobić.