Fizyczne czy logiczne / nietrwałe usuwanie rekordu bazy danych?

Jaka jest zaleta wykonywania logicznego / nietrwałego usuwania rekordu (tj. Ustawienia flagi stwierdzającej, że rekord został usunięty) w porównaniu z faktycznym lub fizycznym usuwaniem rekordu?

Czy to powszechna praktyka?

Czy to jest bezpieczne?

Zaletą jest to, że zachowujesz historię (dobrą do inspekcji) i nie musisz martwić się o kaskadowe usuwanie przez różne inne tabele w bazie danych, które odwołują się do usuwanego wiersza. Wadą jest to, że musisz zakodować wszystkie metody raportowania / wyświetlania, aby uwzględnić flagę.

O ile jest to powszechna praktyka - powiedziałbym, że tak, ale jak ze wszystkim, to, czy z niej skorzystasz, zależy od Twoich potrzeb biznesowych.

EDYCJA: Przemyślana inna wada - jeśli masz unikalne indeksy w tabeli, usunięte rekordy nadal będą zajmować „jeden” rekord, więc musisz kodować również tę możliwość (na przykład tabela użytkownika, która ma unikalny indeks nazwa użytkownika; Usunięty rekord nadal blokowałby nazwę użytkownika usuniętego użytkownika dla nowych rekordów. Pomijając ten problem, możesz dodać identyfikator GUID do kolumny usuniętej nazwy użytkownika, ale jest to bardzo hakerskie obejście, którego nie polecam. Prawdopodobnie w takiej sytuacji lepiej mieć po prostu regułę, że raz użyta nazwa użytkownika nie może zostać zastąpiona).

Czy usuwanie logiczne jest powszechną praktyką? Tak, widziałem to w wielu miejscach. Czy są bezpieczne? To naprawdę zależy, czy są mniej bezpieczne niż dane przed ich usunięciem?

Kiedy byłem liderem technicznym, zażądałem od naszego zespołu, aby zachowywał wszystkie dane, wiedziałem wtedy, że będziemy używać tych wszystkich danych do tworzenia różnych aplikacji BI, chociaż wtedy nie wiedzieliśmy, jakie będą wymagania być. Chociaż było to dobre z punktu widzenia audytu, rozwiązywania problemów i raportowania (to była strona e-commerce / narzędzi do transakcji B2B, a jeśli ktoś używał narzędzia, chcieliśmy to zarejestrować, nawet jeśli jego konto zostało później wyłączone), miał kilka wad.

Wady obejmują (nie licząc innych już wspomnianych):

1. Wydajność Implikacje związane z przechowywaniem wszystkich tych danych, opracowujemy różne strategie archiwizacji. Na przykład jeden obszar aplikacji zbliżał się do generowania około 1 Gb danych tygodniowo.
2. Koszt utrzymania danych rośnie z czasem, podczas gdy miejsce na dysku jest tanie, ilość infrastruktury do przechowywania i zarządzania terabajtami danych, zarówno online, jak i offline, jest duża. Nadmiarowość zajmuje dużo miejsca, a ludzie mają dużo czasu, aby zapewnić szybkie tworzenie kopii zapasowych itp.

Decydując się na logiczne, fizyczne usuwanie lub archiwizację, zadałbym sobie następujące pytania:

1. Czy te dane mogą wymagać ponownego wstawienia do tabeli? Na przykład konta użytkowników pasują do tej kategorii, ponieważ możesz aktywować lub dezaktywować konto użytkownika. W takim przypadku najbardziej sensowne jest usuwanie logiczne.
2. Czy przechowywanie danych ma jakąś wartość? Jeśli tak, to ile danych zostanie wygenerowanych. W zależności od tego wybrałbym logiczne usunięcie lub wdrożyłbym strategię archiwizacji. Pamiętaj, że zawsze możesz archiwizować logicznie usunięte rekordy.

Może być trochę za późno, ale radzę wszystkim zapoznać się z postem na blogu Pinal Dave dotyczącym usuwania logicznego / nietrwałego:

Po prostu w ogóle nie lubię tego rodzaju projektu [usuwanie nietrwałe]. Jestem zwolennikiem architektury, w której tylko niezbędne dane powinny znajdować się w jednej tabeli, a niepotrzebne dane powinny być przenoszone do tabeli zarchiwizowanej. Zamiast śledzić kolumnę isDeleted sugeruję użycie dwóch różnych tabel: jednej z zamówieniami, a drugiej z usuniętymi zamówieniami. W takim przypadku będziesz musiał utrzymywać oba te stoliki, ale w rzeczywistości jest on bardzo łatwy w utrzymaniu. Kiedy piszesz instrukcję UPDATE w kolumnie isDeleted, napisz INSERT INTO innej tabeli i usuń ją z oryginalnej tabeli. Jeśli sytuacja jest wycofywana, napisz kolejne INSERT INTO i DELETE w odwrotnej kolejności. Jeśli martwisz się niepowodzeniem transakcji, zawiń ten kod w TRANSACTION.

Jakie są zalety mniejszego stołu w porównaniu z większym stołem w opisanych powyżej sytuacjach?

• Mniejszy stół jest łatwy w utrzymaniu
• Operacje odbudowy indeksu są znacznie szybsze
• Przeniesienie danych archiwalnych do innej grupy plików zmniejszy obciążenie podstawowej grupy plików (biorąc pod uwagę, że wszystkie grupy plików znajdują się w innym systemie) - przyspieszy to również tworzenie kopii zapasowej.
• Statystyki będą często aktualizowane ze względu na mniejszy rozmiar, co będzie wymagało mniej zasobów.
• Rozmiar indeksu będzie mniejszy
• Wydajność stołu poprawi się przy mniejszym rozmiarze stołu.

Jestem programistą NoSQL i podczas mojej ostatniej pracy pracowałem z danymi, które zawsze były dla kogoś krytyczne, a jeśli zostały usunięte przez przypadek w tym samym dniu, w którym zostały utworzone, nie mogłem ich znaleźć w ostatniej kopii zapasowej od wczoraj! W takiej sytuacji miękkie usuwanie zawsze uratowało sytuację.

Dokonałem miękkiego usunięcia przy użyciu znaczników czasu, rejestrując datę usunięcia dokumentu:

IsDeleted = 20150310  //yyyyMMdd

W każdą niedzielę pewien proces przechodził przez bazę danych i sprawdzał IsDeletedpole. Jeśli różnica między bieżącą datą a datownikiem była większa niż N dni, dokument został trwale usunięty. Biorąc pod uwagę, że dokument nadal jest dostępny w jakiejś kopii zapasowej, można było to bezpiecznie zrobić.

EDYCJA: Ten przypadek użycia NoSQL dotyczy dużych dokumentów tworzonych w bazie danych, dziesiątek lub setek dziennie, ale nie tysięcy czy milionów. Generalnie były to dokumenty ze statusem, danymi i załącznikami procesów workflow. To był powód, dla którego istniała możliwość usunięcia przez użytkownika ważnego dokumentu. Ten użytkownik może być kimś z uprawnieniami administratora, a może właścicielem dokumentu, żeby wymienić tylko kilku.

TL; DR Moim przypadkiem użycia nie był Big Data. W takim przypadku będziesz potrzebować innego podejścia.

Jednym ze wzorców, których użyłem, jest utworzenie tabeli lustrzanej i dołączenie wyzwalacza do tabeli podstawowej, więc wszystkie usunięcia (i aktualizacje, jeśli są wymagane) są rejestrowane w tabeli lustrzanej.

Pozwala to na „rekonstrukcję” usuniętych / zmienionych rekordów i nadal można trwale usuwać w tabeli podstawowej i utrzymywać ją „w czystości” - umożliwia również tworzenie funkcji „cofnij”, a także można zapisać datę, godzinę i użytkownik, który wykonał akcję w lustrzanym stole (nieocenione w sytuacjach polowania na czarownice).

Inną zaletą jest to, że nie ma szans na przypadkowe uwzględnienie usuniętych rekordów podczas odpytywania z podstawowego, chyba że celowo zadasz sobie trud dołączenia rekordów z tabeli lustrzanej (możesz chcieć pokazać aktualne i usunięte rekordy).

Kolejną zaletą jest to, że tabela lustrzana może być czyszczona niezależnie, ponieważ nie powinna mieć żadnych rzeczywistych odniesień do klucza obcego, co czyni tę operację stosunkowo prostą w porównaniu do usuwania z tabeli podstawowej, która używa usuwania miękkiego, ale nadal ma połączenia referencyjne z innymi tabelami.

Jakie inne zalety? - świetnie, jeśli masz wielu programistów pracujących nad projektem, wykonujących odczyty w bazie danych z mieszanymi umiejętnościami i dbałością o poziomy szczegółów, nie musisz siedzieć w nocy z nadzieją, że jeden z nich nie zapomniał o nie uwzględnieniu usuniętych rekordy (lol, Not Include Deleted Records = True), co powoduje takie rzeczy, jak zawyżanie, powiedzmy, że klienci mają dostępną pozycję gotówkową, z którą następnie kupują akcje (tj. jak w systemie transakcyjnym), kiedy pracujesz z systemami transakcyjnymi, ty bardzo szybko przekonają się, jaką wartość mają solidne rozwiązania, mimo że mogą one mieć nieco więcej początkowego „narzutu”.

Wyjątki:
- jako wskazówka, użyj miękkiego usuwania dla danych „referencyjnych”, takich jak użytkownik, kategoria, itp. Oraz twardego usuwania do tabeli lustrzanej dla danych typu „fakt”, tj. Historii transakcji.

Często używam usuwania logicznego - uważam, że działa dobrze, gdy również sporadycznie archiwizujesz `` usunięte '' dane w zarchiwizowanej tabeli (którą można przeszukiwać w razie potrzeby), dzięki czemu nie ma szans wpłynąć na wydajność aplikacji.

Działa dobrze, ponieważ nadal masz dane, jeśli kiedykolwiek poddasz się audytowi. Jeśli usuniesz go fizycznie, zniknie !

Jestem wielkim fanem usuwania logicznego, szczególnie w przypadku aplikacji branżowych lub w kontekście kont użytkowników. Moje powody są proste: często nie chcę, aby użytkownik mógł już korzystać z systemu (więc konto zostaje oznaczone jako usunięte), ale jeśli usunęliśmy użytkownika, stracilibyśmy całą jego pracę i tym podobne.

Innym typowym scenariuszem jest to, że użytkownicy mogą zostać ponownie utworzeni chwilę po usunięciu. O wiele przyjemniejszym doświadczeniem dla użytkownika jest posiadanie wszystkich swoich danych tak, jak było przed ich usunięciem, zamiast konieczności ich ponownego tworzenia.

Zwykle myślę o usuwaniu użytkowników jako o „zawieszaniu” ich na czas nieokreślony. Nigdy nie wiadomo, kiedy zgodnie z prawem będą musieli wrócić.

Prawie zawsze usuwam nietrwałe i oto dlaczego:

• możesz przywrócić usunięte dane, jeśli klient Cię o to poprosi. Bardziej zadowoleni klienci dzięki miękkim usunięciom. Przywracanie określonych danych z kopii zapasowych jest skomplikowane
• szukanie isdeletedwszędzie nie jest problemem, i tak musisz sprawdzić userid(jeśli baza danych zawiera dane od wielu użytkowników). Możesz wymusić sprawdzenie za pomocą kodu, umieszczając te dwa sprawdzenia na oddzielnej funkcji (lub użyj widoków)
• wdzięczne usuwanie. Użytkownicy lub procesy zajmujące się usuniętymi treściami będą ją „widzieć” do następnego odświeżenia. Jest to bardzo pożądana funkcja, jeśli proces przetwarza dane, które są nagle usuwane
• synchronizacja: jeśli chcesz zaprojektować mechanizm synchronizacji między bazą danych a aplikacjami mobilnymi, łatwiejsze do wdrożenia będzie usuwanie miękkie

Odp .: „Czy to jest bezpieczne?” - to zależy od tego, co masz na myśli.

Jeśli masz na myśli, że wykonując fizyczne usuwanie, uniemożliwisz komukolwiek znalezienie usuniętych danych , to tak, to mniej więcej prawda; bezpieczniej jest fizycznie usuwać wrażliwe dane, które należy usunąć, ponieważ oznacza to, że zostały one trwale usunięte z bazy danych. (Należy jednak pamiętać, że mogą istnieć inne kopie danych, o których mowa, takie jak kopia zapasowa, dziennik transakcji lub zapisana wersja z tranzytu, np. Sniffer pakietów - tylko dlatego, że usuniesz z bazy danych, nie gwarancja, że ​​nie został zapisany gdzie indziej.)

Jeśli masz na myśli, że wykonując usuwanie logiczne, Twoje dane są bezpieczniejsze, ponieważ nigdy nie stracisz żadnych danych , to również prawda. Jest to dobre dla scenariuszy audytu; Staram się projektować w ten sposób, ponieważ przyznaje się do podstawowego faktu, że po wygenerowaniu danych nigdy tak naprawdę nie znikną (zwłaszcza jeśli kiedykolwiek miał możliwość, powiedzmy, buforowania przez wyszukiwarkę internetową). Oczywiście prawdziwy scenariusz audytu wymaga, aby nie tylko usuwanie było logiczne, ale także rejestrowanie aktualizacji, wraz z czasem zmiany i aktorem, który dokonał zmiany.

Jeśli masz na myśli, że dane nie wpadną w ręce nikogo, kto nie powinien ich widzieć, to zależy to całkowicie od Twojej aplikacji i jej struktury bezpieczeństwa. Pod tym względem usuwanie logiczne nie jest bardziej ani mniej bezpieczne niż cokolwiek innego w Twojej bazie danych.

Zdecydowanie się nie zgadzam z logicznym usuwaniem, ponieważ jesteś narażony na wiele błędów.

Przede wszystkim zapytania, każde zapytanie musi zadbać o pole IsDeleted, a przy złożonych zapytaniach prawdopodobieństwo wystąpienia błędu wzrasta.

Po drugie wydajność: wyobraź sobie tabelę z 100000 rekordami z tylko 3 aktywnymi, teraz pomnóż tę liczbę dla tabel w Twojej bazie danych; inny problem z wydajnością to możliwy konflikt z nowymi rekordami ze starymi (usuniętymi).

Jedyną zaletą, jaką widzę, jest historia rekordów, ale są inne sposoby na osiągnięcie tego wyniku, na przykład możesz stworzyć tabelę logowania, w której możesz zapisać informacje: TableName,OldValues,NewValues,Date,User,[..]gdzie *Valuesmożna varchari wpisać szczegóły w tym formularzu fieldname : value; [..] lub zapisz informacje jakoxml .

Wszystko to można osiągnąć za pomocą kodu lub wyzwalaczy, ale jesteś tylko JEDNYM stołem z całą swoją historią. Inną opcją jest sprawdzenie, czy określony silnik bazy danych obsługuje natywną obsługę śledzenia zmian, na przykład w bazie danych SQL Server istnieje SQL Track Data Change.

Kiedyś robiłem nietrwałe usuwanie, aby zachować stare rekordy. Zdałem sobie sprawę, że użytkownicy nie zawracają sobie głowy przeglądaniem starych płyt tak często, jak myślałem. Jeśli użytkownicy chcą przeglądać stare rekordy, mogą po prostu przeglądać je z archiwum lub tabeli inspekcji, prawda? Więc jaka jest zaleta usuwania nietrwałego? Prowadzi tylko do bardziej złożonych instrukcji zapytania itp.

Oto rzeczy, które zaimplementowałem, zanim zdecydowałem się już nie usuwać nietrwałe:

1. wdrożyć audyt, rejestrować wszystkie czynności (dodawać, edytować, usuwać). Upewnij się, że nie ma klucza obcego połączonego z audytem i upewnij się, że ta tabela jest zabezpieczona i nikt nie może usunąć poza administratorami.

2. określić, które tabele są uważane za „tabele transakcyjne”, które najprawdopodobniej będą przechowywane przez długi czas i bardzo prawdopodobne, że użytkownik może chcieć przejrzeć wcześniejsze rekordy lub raporty. Na przykład; transakcja zakupu. W tabeli tej należy nie tylko przechowywać identyfikator tabeli głównej (np. Id-działu), ale także dodatkowe informacje, takie jak nazwa, jako odniesienie (np. Nazwa-działu) lub inne pola niezbędne do raportowania.

3. Zaimplementuj „aktywny / nieaktywny”, „włącz / wyłącz” lub „ukryj / pokaż” rekord tabeli głównej. Dlatego zamiast usuwać rekord, użytkownik może wyłączyć / dezaktywować rekord główny. W ten sposób jest dużo bezpieczniej.

Tylko moja opinia za dwa centy.

Logiczne usunięcia, jeśli są trudne w odniesieniu do integralności.

Jest to słuszne rozwiązanie, gdy istnieje aspekt czasowy danych w tabeli (są one ważne od FROM_DATE - TO_DATE).

W przeciwnym razie przenieś dane do tabeli inspekcji i usuń rekord.

Na plus:

Jest to łatwiejszy sposób na przywrócenie (jeśli to w ogóle możliwe).

Łatwo jest zobaczyć, jaki był stan w określonym momencie.

Jest to dość standardowe w przypadkach, w których chcesz zachować historię (np. Konta użytkowników, o których wspomina @Jon Dewees). I z pewnością jest to świetny pomysł, jeśli istnieje duża szansa, że ​​użytkownicy poproszą o usunięcie plików.

Jeśli obawiasz się logiki odfiltrowywania usuniętych rekordów z zapytań, które stają się nieczytelne i tylko komplikują zapytania, możesz po prostu zbudować widoki, które wykonują filtrowanie za Ciebie i używać zapytań przeciwko temu. Zapobiegnie to wyciekowi tych rekordów w rozwiązaniach do raportowania i tym podobnych.

Istnieją wymagania wykraczające poza projekt systemu, na które należy odpowiedzieć. Jaki jest wymóg prawny lub ustawowy w zakresie przechowywania dokumentacji? W zależności od tego, czego dotyczą wiersze, może istnieć prawny wymóg przechowywania danych przez określony czas po ich „zawieszeniu”.

Z drugiej strony może być wymagane, aby po „usunięciu” rekordu został on rzeczywiście i nieodwołalnie usunięty. Zanim podejmiesz decyzję, porozmawiaj z interesariuszami.

Aplikacje mobilne zależne od synchronizacji mogą narzucać stosowanie usuwania logicznego, a nie fizycznego: serwer musi być w stanie wskazać klientowi, że rekord został (oznaczony jako) usunięty, a to może nie być możliwe, jeśli rekordy zostały usunięte fizycznie.

Nie pozwalają, aby baza danych działała tak, jak powinna, sprawiając, że funkcje kaskadowe są bezużyteczne.

W przypadku prostych rzeczy, takich jak wstawianie, w przypadku ponownego wstawiania, kod za nim podwaja się.

Nie możesz po prostu wstawić, zamiast tego musisz sprawdzić istnienie i wstawić, jeśli nie istnieje wcześniej, lub zaktualizować flagę usunięcia, jeśli tak, jednocześnie aktualizując wszystkie inne kolumny do nowych wartości. Jest to postrzegane jako aktualizacja dziennika transakcji bazy danych, a nie nowa wstawka powodująca niedokładne dzienniki inspekcji.

Powodują problemy z wydajnością, ponieważ tabele są zapychane zbędnymi danymi. Robi spustoszenie w indeksowaniu, szczególnie w przypadku wyjątkowości.

Nie jestem wielkim fanem usuwania logicznego.

Odpowiadając na komentarz Tohida, napotkaliśmy ten sam problem, w którym chcieliśmy zachować historię zapisów, a także nie byliśmy pewni, czy chcemy is_deleted felietonów, czy nie.

Mówię o naszej implementacji Pythona i podobnym przypadku użycia, w który trafiliśmy.

Napotkaliśmy https://github.com/kvesteri/sqlalchemy-continuum który jest łatwym sposobem na uzyskanie tabeli wersji dla odpowiedniej tabeli. Minimalna liczba wierszy kodu i historia przechwytywania do dodawania, usuwania i aktualizowania.

To służy więcej niż tylko is_deleted kolumnom. Zawsze możesz odwołać się do tabeli wersji, aby sprawdzić, co się stało z tym wpisem. Czy wpis został usunięty, zaktualizowany lub dodany.

W ten sposób w ogóle nie musieliśmy mieć is_deletedkolumny, a nasza funkcja usuwania była dość trywialna. W ten sposób nie musimy również pamiętać o zaznaczaniu is_deleted=Falseżadnego z naszych interfejsów API.

Miękkie usuwanie to praktyka programistyczna stosowana w większości aplikacji, gdy dane są bardziej istotne. Rozważmy przypadek aplikacji finansowej, w której usunięcie przez pomyłkę użytkownika końcowego może być fatalne w skutkach. Dzieje się tak, gdy istotne staje się usuwanie nietrwałe. W przypadku usuwania nietrwałego użytkownik w rzeczywistości nie usuwa danych z rekordu, ale jest oznaczany jako IsDeleted na wartość true (zgodnie z normalną konwencją).

W EF 6.x lub EF 7 dalej Softdelete jest dodawany jako atrybut, ale na razie musimy utworzyć niestandardowy atrybut.

Zdecydowanie polecam SoftDelete w projekcie bazy danych i jest to dobra konwencja dla praktyki programistycznej.

W większości przypadków softdeleting jest używany, ponieważ nie chcesz ujawniać niektórych danych, ale musisz je zachować z powodów historycznych (produkt może zostać wycofany, więc nie chcesz żadnej nowej transakcji z nim, ale nadal musisz pracować z historia transakcji sprzedaży). Nawiasem mówiąc, niektórzy kopiują wartość informacji o produkcie w danych transakcji sprzedaży, zamiast odnosić się do produktu, aby to obsłużyć.

W rzeczywistości wygląda to bardziej jak przeformułowanie widocznej / ukrytej lub aktywnej / nieaktywnej funkcji. Bo takie jest znaczenie „usuwania” w świecie biznesu. Chciałbym powiedzieć, że Terminatorzy mogą usuwać ludzi, ale szef po prostu ich zwalnia.

Ta praktyka jest dość powszechnym wzorcem i jest używana przez wiele aplikacji z wielu powodów. Ponieważ nie jest to jedyny sposób na osiągnięcie tego celu, będziesz miał tysiące ludzi, którzy będą mówić, że to świetne lub bzdury i obie mają całkiem dobre argumenty.

Z punktu widzenia bezpieczeństwa, SoftDelete nie zastąpi zadania Audytu i nie zastąpi również zadania tworzenia kopii zapasowych. Jeśli obawiasz się „wstawiania / usuwania między dwiema kopiami zapasowymi”, powinieneś przeczytać o modelach pełnego lub zbiorczego odzyskiwania. Przyznaję, że SoftDelete może uczynić proces odzyskiwania bardziej trywialnym.

Musisz znać swoje wymagania.

Aby dać alternatywę, mamy użytkowników korzystających z aktualizacji urządzeń zdalnych za pośrednictwem MobiLink. Jeśli usuniemy rekordy z bazy danych serwera, te rekordy nigdy nie zostaną oznaczone jako usunięte w bazach danych klienta.

Więc robimy jedno i drugie. Współpracujemy z naszymi klientami, aby określić, jak długo chcą odzyskać dane. Na przykład zazwyczaj klienci i produkty są aktywne, dopóki nasz klient nie powie, że powinny zostać usunięte, ale historia sprzedaży jest zachowywana tylko przez 13 miesięcy, a następnie jest usuwana automatycznie. Klient może chcieć zachować usuniętych klientów i produkty przez dwa miesiące, ale zachować historię przez sześć miesięcy.

Więc uruchamiamy skrypt z dnia na dzień, który oznacza rzeczy logicznie usunięte zgodnie z tymi parametrami, a następnie dwa / sześć miesięcy później wszystko, co zostało dzisiaj oznaczone jako usunięte logicznie, zostanie trwale usunięte.

Nie chodzi nam o bezpieczeństwo danych niż o posiadanie ogromnych baz danych na urządzeniu klienckim z ograniczoną pamięcią, takim jak smartfon. Klient, który zamawia 200 produktów dwa razy w tygodniu przez cztery lata, będzie miał ponad 81 000 linii historii, z czego 75% nie dba o to, czy zobaczy.

Wszystko zależy od przypadku użycia systemu i jego danych.

Na przykład, jeśli mówisz o systemie regulowanym przez rząd (np. Systemie w firmie farmaceutycznej, który jest uważany za część systemu jakości i musi przestrzegać wytycznych FDA dotyczących dokumentacji elektronicznej), to do cholery lepiej nie usuwać twardo! Audytor z FDA może przyjść i poprosić o wszystkie zapisy w systemie dotyczące numeru produktu ABC-123, a wszystkie dane będą lepiej dostępne. Jeśli właściciel procesu biznesowego mówi, że system nie powinien pozwalać nikomu na używanie produktu o numerze ABC-123 na nowych rekordach w przyszłości, użyj metody usuwania nietrwałego, aby uczynić ją „nieaktywną” w systemie, zachowując jednocześnie dane historyczne.

Być może jednak Twój system i jego dane mają przypadek użycia, taki jak „śledzenie pogody na biegunie północnym”. Może robisz odczyty temperatury raz na godzinę, a na koniec dnia agregujesz średnią dzienną. Być może dane godzinowe nie będą już nigdy używane po agregacji i po utworzeniu agregacji trwale usuniesz odczyty godzinowe. (To jest zmyślony, trywialny przykład).

Chodzi o to, że wszystko zależy od przypadku użycia systemu i jego danych, a nie decyzji, którą należy podjąć z czysto technologicznego punktu widzenia.

Dobrze! Jak wszyscy mówili, to zależy od sytuacji.

Jeśli masz indeks w kolumnie, takiej jak nazwa użytkownika lub identyfikator e-mail - i nigdy nie spodziewasz się ponownego użycia tej samej nazwy użytkownika lub adresu e-mail; możesz przejść z miękkim usuwaniem.

To powiedziawszy, zawsze sprawdzaj, czy operacja SELECT używa klucza podstawowego. Jeśli instrukcja SELECT używa klucza podstawowego, dodanie flagi z klauzulą ​​WHERE nie zrobiłoby dużej różnicy. Weźmy przykład (pseudo):

Użytkownicy tabeli (ID użytkownika [klucz podstawowy], EmailID, IsDeleted)

SELECT * FROM Users where UserID = 123456 and IsDeleted = 0

To zapytanie nie będzie miało wpływu na wydajność, ponieważ kolumna UserID ma klucz podstawowy. Początkowo skanuje tabelę na podstawie PK, a następnie wykonuje następny warunek.

Przypadki, w których usuwanie miękkie nie może w ogóle działać:

Rejestracja w większości witryn internetowych traktuje EmailID jako unikalną identyfikację. Doskonale wiemy, że raz użyty EmailID na stronie takiej jak Facebook czy G + nie może być używany przez nikogo innego.

Przychodzi taki dzień, kiedy użytkownik chce usunąć swój profil ze strony. Teraz, jeśli wykonasz logiczne usunięcie, ten użytkownik nie będzie mógł się więcej zarejestrować. Ponadto ponowna rejestracja przy użyciu tego samego EmailID nie oznaczałaby przywrócenia całej historii. Wszyscy wiedzą, że usunięcie oznacza usunięcie. W takich scenariuszach musimy dokonać fizycznego usunięcia. Aby jednak zachować całą historię konta, zawsze należy archiwizować takie zapisy albo w tabelach archiwum, albo w tabelach usuniętych.

Tak, w sytuacjach, gdy mamy wiele zagranicznych stołów, obsługa jest dość uciążliwa.

Należy również pamiętać, że usuwanie nietrwałe / logiczne spowoduje zwiększenie rozmiaru tabeli, a więc rozmiaru indeksu.

Odpowiedziałem już w innym poście . Myślę jednak, że moja odpowiedź bardziej pasuje do tego pytania.

Moje praktyczne rozwiązanie dla miękkiego kasowania jest archiwizacji tworząc nową tabelę z następującymi kolumnami: original_id, table_name, payload, (i opcjonalny klucz podstawowy `id).

Gdzie original_idto oryginalny identyfikator usuniętego rekordu, table_name to nazwa tabeli usuniętego rekordu ( "user"w twoim przypadku), payloadto ciąg znaków JSON ze wszystkich kolumn usuniętego rekordu.

Proponuję również utworzenie indeksu w kolumnie original_iddla późniejszego pobierania danych.

W ten sposób archiwizuje dane. Będziesz miał te zalety

• Śledź wszystkie dane w historii
• Miej tylko jedno miejsce do archiwizacji rekordów z dowolnej tabeli, niezależnie od struktury tabeli usuniętego rekordu
• Nie martw się o unikalny indeks w oryginalnej tabeli
• Nie martw się o sprawdzenie zagranicznego indeksu w oryginalnej tabeli
• WHEREW każdym zapytaniu nie ma już klauzuli sprawdzającej usunięcie

Rzecz jest już dyskusja tutaj wyjaśniając dlaczego miękkie usunięcie nie jest to dobry pomysł w praktyce. Usuwanie nietrwałe wprowadza pewne potencjalne problemy w przyszłości, takie jak liczenie rekordów, ...

Zalety to ochrona / utrwalanie danych. Zwolnieniem byłoby obniżenie wydajności podczas wykonywania zapytań lub pobierania danych z tabel ze znaczną liczbą miękkich usunięć. W naszym przypadku używamy kombinacji obu: jak wspominali inni w poprzednich odpowiedziach, soft-delete users/clients/customersna przykład my , oraz hard-deletew items/products/merchandisetabelach, w których znajdują się zduplikowane rekordy, które nie muszą być pilnowane.

To zależy od przypadku, rozważ poniższe kwestie:

Zwykle nie ma potrzeby „nietrwałego usuwania” rekordu. Niech to będzie proste i szybkie. np. usunięcie produktu, który nie jest już dostępny, więc nie musisz sprawdzać, czy produkt nie jest usuwany nieuchronnie z całej aplikacji (liczba, lista produktów, polecane produkty itp.).

Można jednak rozważyć „nietrwałe usuwanie” w modelu hurtowni danych. np. przeglądasz stary paragon na usuniętym produkcie. *