Usuwanie danych konta :: 4programmers.net

0

Musze napisac skrypt, ktory bedzie usuwal wszysktie dane dotyczace danego klienta i jego konta. Tak, mamy skonstrulowane umowy z klientami, ze po danym okresie mamy automatycznie usunac wszystkie dane zwiazane z jego kontem w naszym systemie.

Chce napisac API endpoint, ktory wywolam do usuniecia obenych konto do usuniecia oraz uzyje tego endpoint w cron job. Wydaje, mi sie, ze powinno byc ok?

Zastanawiam sie tylko nad jedna kwestia. W obecnej bazie danych mamy blisko 300 tabel. Wiekszosc z nich zawiera dane klienta, prywantne i mniej prywatne dane, logi etc etc. Niestety tabele niezabardzo uzywaja PR czy FK, wiec delete cascade nie zadziala. Pytanie, jak to zopytmalizowac. Nie chce mi sie pisac niemal, ze 300 pojedynczych DELETE zapytan do bazy danych. Moze ktos pisal cos podobnego? Jak to rozwizaliscie? Niby prosta sprawa, ale problemem jest spora ilosc danych do usunieca.

Czy oplaca sie wywolac te zapytania w SQL transaction?

3

Ciężko uwierzyć że trzymacie dane klientów w ponad 150 tabelach (większośc z 300). Może macie tam ID'ki które odwołują się do wlasciwych danych.
Jak bym to rozwiązał? Mam kilka pomysłów

zaorał tak skonstruowaną bazę danych
nadał priorytety przy kasowaniu - np wrzucałby info o ID którego delikwenta kasować, a potem powolutku kasował te dane - np najpierw dane osobowe, potem jakieś wpisy powiązane z ID usera itd itd (to możnaby ogarnąć w cronie czy w kolejkach)
zacisnął zęby i napisał te 150-300 DELETE'ów. Czy to dużo? jeśli będziesz to kasował po ID to w czym problem? zbierasz tylko tabele i nazwy kolumn i jedziesz z koksem (robota może na 2~3 dni max)
poza tym zainteresowałbym się tym czy naprawdę macie tyle danych osobowych, sprawdziłbym te umowy albo poprosił o dokładny wykaz co faktycznie jest daną osobową (czy taką które zostały ujęte w umowie) - bo może się okazać że nie ma potrzeby usuwania np. komentarzy czy zamówień usera, a wystarczy tylko dać info "Użytkownik usunięty".
poza tym.... sprawdziłbym jakoś czy taka umowa jest zgodna z prawem podatkowym w danym kraju - jeśli coś było sprzedawane to dane z takich transakcji należy przechowywać przez jakiś czas i to że klient chce mieć skasowane dane nie znaczy zbyt wiele w takim przypadku.
oprócz tego nie wystawiałbym żadnego API endpointa, tylko zrobił konsolowego commanda - prostsze to w użytkowaniu, podawałbyś tylko ID usera/organizacji czy czegokolweik co tam obsługujecie. Nie miałbyś też potrzeby zabezpieczania tego endpointu (no ale to zależy od tego jak wygląda wasza infrastruktura i architektura)
sprawdziłbym czy zaciemnianie danych nie przyniosłoby takiego samego efektu, bo kto wie czy to nie spełniłoby wymagań z waszej umowy.

Na tę chwilę nie wiemy jaka jest umowa/infrastruktura/architektura - więc ciężko napisać coś konkretnego.
A co do transakcji - to co Twoim zdaniem może pójść nie tak przy takiej operacji i jak to wpłynie na pozostałe części systemu? Moim zdaniem jeśli np usuniesz dane ze 149 tabel i w jednej coś zostanie - to chyba podczas takiego procesu usuwania logujesz co poszło nie tak prawda? Prawda? Bo jeśli tak to może warto by było pochylić się nad tym i zrobić to tak, by taki problem nie pojawiał się więcej.

Pisałeś że nie macie PR czy FK (rozumiem ze PR to Primary Key, ale to chyba sie zapisuje jako PK, a FK jako Foreign Key <- i tu jest wsio ok z nazewnictwem), więc za bardzo nie wiem czy miałby powstać problem z robieniem delete'a - jeśli DELETE FROM table WHERE some_id=1 może u was powodować błędy, to lepiej naprawcie czym szybciej cały system. Rozumiem, ze skasowanie danych z tabeli A, a pozostawienie ich w B może mieć wpływ na resztę systemu (np macie tabele "zamówienia" z ID usera, i usera usuneliscie, a zamowienia zostaly - to tak, to moze wam rozłożyć system). Ale nie sądzę by na poziomie prostych delete'ów coś wam mogło pójść nie tak przy ich kasowaniu.

Mogę się mylić - także proszę mądrzejszych forumowiczów o korektę.

6

Też mi śmierdzi to usuwanie danych klientów głównie ze względów prawnych i regulacji obowiązujących. W każdym systemie przy którym pracowałem/tworzyłem wyglądało to tak, że z klientem ustala się co jest daną osobową/wrażliwą, a co nie i na końcu dokonuje anonimizacji tych pól, do tego oznaczało się klienta jako deleted.

0

markone_dev napisał(a):

Też mi śmierdzi to usuwanie danych klientów głównie ze względów prawnych i regulacji obowiązujących. W każdym systemie przy którym pracowałem/tworzyłem wyglądało to tak, że z klientem ustala się co jest daną osobową/wrażliwą, a co nie i na końcu dokonuje anonimizacji tych pól, do tego oznaczało się klienta jako deleted.

Nie znam dokladnie szczegolow, nie wiem czy PM zna, albo nie chce sie podzielic. Sam pytalem czy usuwanie ma byc dokonane wylacznie na danych wrazliwych konta, czy na wszystkich tabelach, gdzie znajda sie jakiekolwiek dane klienta??

Co masz na mysli, ze względów prawnych i regulacji obowiązujących? Ten system ma wiekszosc klientow w USA. Moze to chodzi o prawo obowiazujacym w stanach, nie wiem. Z tego co rozumiem, chce zrobic hard delete, pewnie na wsyzstkich danych, ale nie rozumiem dlaczego. Raz, ze masa roboty. Niby mam usunac konta, ktore nie maja zadnej aktywnosci przez 3+ lat. Dla mnie troche to smierdzi, jakas dziwna robota :D

3

Nie znam prawa w USA. Przykładowo w EU jest GDPR i jednym z wymogów GDPR jest prawo do bycia zapomnianym, nakazujące administratorowi danych usunięcie informacji na żądanie zainteresowanego. Do tego dochodzi też retencja danych, czyli przechowujemy dane tak długo ile to faktycznie jest wymagane. Czasem ten okres jest uregulowany prawnie, a czasem nie i firma może zdecydować o trzymaniu danych dłużej niż jest to wymagane prawnie do np. celów statystycznych.

No i dochodzimy do kwestii jak te dane usunąć, czy robić hard delete czy soft delete? Z tego co się orientuję nie ma tu jednoznacznej odpowiedzi. Przynajmniej regulacje które znam o tym nie wspominają. Ja w swoich systemach zawsze robiłem soft delete i anonimizację, ponieważ te dane (zanonimizowane) były później jeszcze wykorzystywane do celów raportowych i analitycznych.

Widocznie w twoim projekcie uznano, że minął już 3 letni okres retencji danych i firma jest zobligowana prawnie aby usunąć dane użytkowników. A że nie mają planów wykorzystywać tych danych dalej zdecydowano się na całkowite ich usunięcie.

Pytanie jeszcze o pozostałe systemy w których te dane mogą się znajdować, bo były robione integracje. Stamtąd też trzeba je usunąć.

0

Troche zastanawiam sie jakie moga byc skutki uboczne takiego usuwania rekordow z bazy daych. Np czy zdrowe jest dla bazy danych pozostawiania dziur w PK ID? Albo jak musze usunac z 50 tys czy 80 tys rekordow z jednej tabeli na ktorej jest index. Czy to nie spowoduje przebudowy takiego indexu? Za czym idzie zalozenie lock ma tabele podczas przebudowy tego indexu? Nie wiem, pierwszy raz stykam sie z potrzeba usuwania danych z DB. Szczerze, chyba srednio mi sie to podoba, raczej unikalbym takich zabiegow. Troche jest to dla mnie kontrowersyjne.

0

Nasza baza danych ma ponad 1160 GB. I gosc z SRE chce usunac dane dla lepszej wydajnosci DB. lol. Jest argument :D Tzn ten z prawny element dalej tez jest argumentem.

0

Czyli usuwac dane i tyle? Moge napisac 250 DELETE zapytan. Dla mnie to troche pracy bedzie i dosc ryzykowenej jak cos pojdzie po mojej mysli. Pracuje jako kontraktor. Jezeli firma albo klient zdecyduja sie moga isc na droge sadowa i zadac odszkodowania za usuniecie danych.

2

Jaki masz cel biznesowy? Usunąć te dane żeby ich nie było, czy masz poprawić działanie bazy?
Bo jak to drugie to od tego są mechanizmy jak skalowanie.
Naprawdę trzymacie te same dane w 250 tabelach?
Dobrze zrozumiałem? Nie możecie tego jakoś wydzielić i jak już zrobić on delete cascade?
Nawet jak zrobisz magiczny endpoint na 250 delete to co jak ktoś się pomyli i usunie nie tego John Doe co potrzeba?
Dla mnie to co opsiuejsz to tykającą bomba na polu minowym.

0

jurek1980 napisał(a):

Jaki masz cel biznesowy? Usunąć te dane żeby ich nie było, czy masz poprawić działanie bazy?
Bo jak to drugie to od tego są mechanizmy jak skalowanie.
Naprawdę trzymacie te same dane w 250 tabelach?
Dobrze zrozumiałem? Nie możecie tego jakoś wydzielić i jak już zrobić on delete cascade?
Nawet jak zrobisz magiczny endpoint na 250 delete to co jak ktoś się pomyli i usunie nie tego John Doe co potrzeba?
Dla mnie to co opsiuejsz to tykającą bomba na polu minowym.

Ponoc w umowie z klientem maja jakas klauzule, ze musza usunac wszystkie dane zwiazane z danym kontem po 3 latach od zaprzestania uzytkowania konta. Dla mnie dalej nie jest takie jednoznaczne co oznacza usuniecie wszystkich danych konta.

Nie trzymamy tych samych danych w 250 tabelach. 250 tabel ma produkcyjna baza danych, tzn jest ich wiecej tyko tak napisalem, latwiej zapamietac. Wiekszosc tych tabel bedzie posiadalo powiazanie z kontem, ale nie wiem czy z danymi konta.

Wiekszosc tych tabel nie posiadac w ogole FK. Musialbym robic na nowo FK. Nie wiem czy w ogole dam rade i czy to czegosc nie zepsuje. Nie chce tworzyc nowych bledow w systemie.

Dla mnie to tez jest tykajaca bomba na polu minowym. Zgadzam sie w 100%. Niby kolega chce robic jakis backup, ale jak on zrobi ten backup cos pojdzie nie tak, to jak odzyskamy dane z 250 tabel dla konta z ID np 99999. Nierealne. Najlepiej, jak ktos by w ogole zapomnial skasowac tych backup'ow :D

0

W obecnej firmie, ktorej pracuje podpisalem tez dokumenty dotyczacej mojej pracy, legal. Dokumenty w symie, ktore chronia firme, a nie mnie. I jak przez przypadke cos sie stanie, to kliencie albo sama firma moze mnie pozwac na naprawde duze pieniadze. Nie wiem, moze tak sie w ogole nie stanie. Ale czytalem, ze data protection to dosc ciezki temat. Zauzmy, ze np jakis pomine jakis tabele i moze byc problem. Albo usune za duzo. Koles z firmy chce, zeby zautomatyzowac usuwanie danych uzytkownika. W sumie troche mnie to przeraza. Wole, zeby osoba sprawdzila jakie konta maja byc usnieta i potwierdzila to przez klikanie w przycisk w systemie. Moge np wyslac emaila z lista kont do usuniecia w momencie, gdy takie konta beda wystepowac. ALe w ogole taki skrypt moze nawyrzacac mase problemow. Nawet jak ktos doda nowa tabele etc. Nie daj Bog, PHP zwariuje i usunie za duzo np przez upgdate wersji PHP czy cos. Zebym pracowal jako pracownik, a nie kontraktor to bym pisal, bo firma ma ubezpiecznie i oni by dostali po lapach nie ja. Ale tutaj, jest inna sytuacja. W ogole dziwie sie, ze firma przyszla z taka masowym usuwaniem danych do kontaktora. Nie wiem moze cos sie stac a moze nie. A co skoncze kiedys wposlprace z ta firma. I np za jakis kilka lat ktos do mnie zadzwoni i powie, ze moj skrypt nie dziala dobrze etc i beda chcieli sie ze mna sadzic?

1

W zakresie podpisanej przez Ciebie umowy raczej nie da się pomóc przez forum.
Myślę też, że ma ona na celu ochronę danych, tak byś np. nie kopiował bazy klientów i np. nie handlował danymi.

PHP raczej nie zwariuje i nie usunie danych. Może to i kiepski język, ale bez przesady.
Napisz w jakiejś korespondencji firmowej do PO czy przełożonego, że widzisz taki i taki problem. Jeśli będziesz miał na mailu: tak Poniatowski, wiemy. Rób! No to co Ci mogą zrobić?

Techniczne rozwiązanie to już zupełnie inna sprawa. Pod kątem technicznym, masz wszystko opisane.

0

Nie mam pojecia. To jest firma ze stanow. Tam lubia sie sadzic. Maja swoje audyty etc. Osobiscie dla mnie troche strach :D Szczegolnie, ze ta baza danych jest jakas pogmatwana. Nie ma foreign keys.

Generalnie uwazam, ze przy usuwaniu danych z ~250 tabel to juz samo w sobie jest ryzykowne. Jak nie ma FK to latwo sie pomylic :D Zle sprawdzisz i nie ma juz tabeli :D

0

No to nie pozostaje nic innego jak pojechać klasykiem:
Weź kredyt, zmień pracę.

0

jurek1980 napisał(a):

No to nie pozostaje nic innego jak pojechać klasykiem:
Weź kredyt, zmień pracę.

lol

Masz Ci odpowiedz.

Wczesniej sam pisales tj ponizej. Wydawalo sie, ze kumasz problem:

Dla mnie to co opsiuejsz to tykającą bomba na polu minowym.

1

No rozumiem. Ale jeśli boisz się to zrobić ze względów prawnych to nie ma jak Ci pomóc przez forum.
Technicznie masz to opisane. Z takim długiem technicznym przynajmniej ja zacząłbym od poprawy bazy danych. I tak już możecie mieć wiersze gdzie klienta nie ma.

0

Z takim długiem technicznym przynajmniej ja zacząłbym od poprawy bazy danych.

Jak bys zaczal poprawe baze danych?

Nie wiem czy dodatnie kluczy obcych bedzie takie proste. Nie wiem jak zachowa sie aplikacja, moze znowu usunie za duzo danych, tym razem z wielu tabel i nie tylko z jednej. Moze bedzie trzeba usnac jakies rekordy, zeby klucz obcy mogl w ogole nie utworzyc.

@jurek1980 Na moim miejscu napisal bys ten skrypt pomimo ryzyka czy nie? :D

0

poniatowski napisał(a):

@jurek1980 Na moim miejscu napisal bys ten skrypt pomimo ryzyka czy nie? :D

Pogadaj ze swoim przełożonym, wyjaśnij mu swoje wątpliwości i stanowczo powiedz, że nie zrobisz tego zadania i szukaj roboty :D

1

Jak pisałem. Napisz maila do przełożonego z listą potencjalnych problemów. Odpowiedź wydrukuj i dołącz do teczki z umową na wypadek sądu jeśli się tego boisz.
Potem możesz już robić drop database.

Czy ja bym zrobił taki skrypt? Z tego co opisujesz o środowisku, nie. Co najwyżej anonimizowałbym wstawiając np 8 gwiazdek w pola wrażliwe typu imię nazwisko, mail. Ale Ty masz wytyczne, Ty masz umowę, Ty masz pewnie kredyt do zapłaty na który musisz zarobić

2

jurek1980 napisał(a):

Jak pisałem. Napisz maila do przełożonego z listą potencjalnych problemów. Odpowiedź wydrukuj i dołącz do teczki z umową na wypadek sądu jeśli się tego boisz.
Potem możesz już robić drop database.

Czy ja bym zrobił taki skrypt? Z tego co opisujesz o środowisku, nie. Co najwyżej anonimizowałbym wstawiając np 8 gwiazdek w pola wrażliwe typu imię nazwisko, mail. Ale Ty masz wytyczne, Ty masz umowę, Ty masz pewnie kredyt do zapłaty na który musisz zarobić

Chyba udalo mi sie przemowic do rozsadku! Bardzo mozliwe, ze nie bedze musial robic hard-delete a wylacznie maskowanie danych. Dalej nie wiem dokladnie jakich danych, ale to juz znacznie lepiej, tak mi sie wydaje.