Cancellazione fisica / logica / soft del record del database?

Qual è il vantaggio di fare una cancellazione logica / soft di un record (ad esempio impostando una bandiera che indica che il record è stato cancellato) invece di cancellare fisicamente o fisicamente il record?

È questa pratica comune?

È sicuro?

I vantaggi sono che si mantiene la cronologia (utile per il controllo) e non si deve preoccuparsi di eseguire il collegamento in cascata di un’eliminazione tramite varie altre tabelle nel database che fanno riferimento alla riga che si sta eliminando. Lo svantaggio è che devi codificare qualsiasi metodo di segnalazione / visualizzazione per tenere conto della bandiera.

Per quanto riguarda se è una pratica comune, direi di sì, ma come con qualsiasi cosa, se la si utilizza dipende dalle esigenze della tua azienda.

EDIT: Pensato a un altro svantaggio – Se sulla tabella sono presenti indici univoci, i record eliminati continueranno a occupare il record “uno”, quindi dovrai codificare anche questa possibilità (ad esempio, una tabella Utente con un indice univoco su username: un record cancellato bloccherebbe comunque il nome utente degli utenti cancellati per i nuovi record, aggirandoti su un GUID alla colonna del nome utente cancellato, ma è una soluzione molto intrattabile che non consiglierei. Probabilmente in quella circostanza sarebbe è meglio avere semplicemente una regola che, una volta usato un nome utente, non possa mai essere sostituito).

Le eliminazioni logiche sono pratiche comuni? Sì, l’ho visto in molti posti. Sono sicuri? Dipende davvero che sono meno sicuri dei dati prima che li cancellassi?

Quando ero un capo tecnico, chiedevo che il nostro team conservasse ogni dato, sapevo che al momento usavamo tutti quei dati per build varie applicazioni di BI, anche se al momento non sapevamo quali sarebbero stati i requisiti essere. Sebbene ciò fosse valido dal punto di vista dell’auditing, della risoluzione dei problemi e dei rapporti (questo era un sito di e-commerce / strumenti per le transazioni B2B, e se qualcuno usava uno strumento, volevamo registrarlo anche se il suo account era stato distriggersto in seguito), aveva diversi aspetti negativi.

Gli svantaggi includono (non compresi gli altri già citati):

  1. Prestazioni Implicazioni di mantenere tutti questi dati, Dobbiamo sviluppare varie strategie di archiviazione. Ad esempio, un’area della domanda si avvicinava a generare circa 1 Gb di dati a settimana.
  2. Il costo di mantenere i dati cresce nel tempo, mentre lo spazio su disco è economico, l’ammontare dell’infrastruttura per mantenere e gestire i territti di dati sia online che offline è molto. Ci vuole molto disco per la ridondanza e il tempo delle persone per garantire che i backup si muovano rapidamente ecc.

Quando decidevo di utilizzare cancellazioni logiche, fisiche o archiviazione, mi ponevo queste domande:

  1. È ansible che questi dati debbano essere reinseriti nella tabella. Ad esempio, gli account utente si adattano a questa categoria in quanto potresti triggersre o distriggersre un account utente. Se questo è il caso, una cancellazione logica ha più senso.
  2. C’è qualche valore intrinseco nella memorizzazione dei dati? In tal caso, quanti dati verranno generati. A seconda di ciò, andrei con una cancellazione logica o implementerò una strategia di archiviazione. Tieni presente che puoi sempre archiviare i record cancellati logicamente.

Sono uno sviluppatore NoSQL e, durante il mio ultimo lavoro, ho lavorato con dati che erano sempre critici per qualcuno e, se è stato cancellato accidentalmente nello stesso giorno in cui è stato creato, non sono stato in grado di trovarlo nell’ultimo backup da ieri! In tale situazione, l’eliminazione soft ha sempre salvato il giorno.

Ho fatto la cancellazione soft utilizzando i timestamp, registrando la data in cui il documento è stato cancellato:

 IsDeleted = 20150310 //yyyyMMdd 

Ogni domenica, un processo camminava sul database e controllava il campo IsDeleted . Se la differenza tra la data corrente e il timestamp era superiore a N giorni, il documento è stato cancellato. Considerando che il documento è ancora disponibile su alcuni backup, è stato sicuro farlo.

EDIT: questo caso d’uso NoSQL riguarda i grandi documenti creati nel database, decine o centinaia di essi ogni giorno, ma non migliaia o milioni. In generale, erano documenti con lo stato, i dati e gli allegati dei processi del stream di lavoro. Questo era il motivo per cui esisteva la possibilità che un utente cancellasse un documento importante. Questo utente potrebbe essere qualcuno con i privilegi di amministratore, o forse il proprietario del documento, solo per citarne alcuni.

TL; DR Il mio caso d’uso non era Big Data. In tal caso, avrai bisogno di un approccio diverso.

Potrebbe essere un po ‘tardi, ma suggerisco a tutti di controllare il post sul blog di Pinal Dave sull’eliminazione logica / soft:

Semplicemente non mi piace affatto questo tipo di design [soft delete]. Sono fermamente convinto dell’architettura in cui solo i dati necessari dovrebbero trovarsi in un’unica tabella e i dati inutili dovrebbero essere spostati in una tabella archiviata. Invece di seguire la colonna isDeleted, suggerisco l’utilizzo di due tabelle diverse: una con gli ordini e un’altra con gli ordini eliminati. In tal caso, dovrai mantenere entrambi i tavoli, ma in realtà è molto facile da mantenere. Quando scrivi l’istruzione UPDATE sulla colonna isDeleted, scrivi INSERT INTO in un’altra tabella e CANCELLA dalla tabella originale. Se la situazione è di rollback, scrivere un altro INSERT INTO e DELETE in ordine inverso. Se sei preoccupato per una transazione fallita, avvolgi questo codice in TRANSACTION.

Quali sono i vantaggi del tavolo più piccolo rispetto alla tabella più grande nelle situazioni sopra descritte?

  • Un tavolo più piccolo è facile da mantenere
  • Le operazioni di ricostruzione dell’indice sono molto più veloci
  • Lo spostamento dei dati di archivio in un altro filegroup ridurrà il carico del filegroup primario (considerando che tutti i filegroup si trovano su sistemi diversi), accelerando anche il backup.
  • Le statistiche saranno frequentemente aggiornate a causa delle dimensioni ridotte e questo richiederà meno risorse.
  • La dimensione dell’indice sarà più piccola
  • Le prestazioni della tabella miglioreranno con una dimensione inferiore della tabella.

Uno schema che ho usato è quello di creare una tabella mirror e colbind un trigger sulla tabella primaria, quindi tutte le eliminazioni (e gli aggiornamenti se lo si desidera) vengono registrati nella tabella mirror.

Questo ti permette di “ribuild” i record cancellati / modificati, e puoi ancora eliminare hard nella tabella principale e tenerlo “pulito” – permette anche la creazione di una funzione “annulla”, e puoi anche registrare la data, l’ora e utente che ha eseguito l’azione nella tabella mirror (inestimabile nelle situazioni di caccia alle streghe).

L’altro vantaggio è che non vi è alcuna possibilità di includere accidentalmente i record cancellati quando si interroga il primario, a meno che non si abbia deliberatamente il problema di includere i record dalla tabella mirror (si potrebbe voler visualizzare i record vivi e cancellati).

Un altro vantaggio è che la tabella mirror può essere eliminata in modo indipendente, in quanto non dovrebbe avere alcun riferimento a una chiave esterna effettiva, rendendo questa un’operazione relativamente semplice rispetto all’eliminazione da una tabella primaria che utilizza eliminazioni software, ma ha ancora connessioni referenziali ad altre tabelle .

Quali altri vantaggi? – ottimo se hai un gruppo di programmatori che lavorano al progetto, facendo letture sul database con abilità miste e attenzione ai livelli di dettaglio, non devi stare sveglio notti sperando che uno di loro non dimentichi di non includere cancellati record (lol, Not Include Deleted Records = True), che si traduce in cose come esagerare dire che i clienti dispongono di posizioni in contanti che poi acquistano alcune condivisioni (ad esempio, come in un sistema di trading), quando lavori con i sistemi di trading, scopriremo molto rapidamente il valore di soluzioni robuste, anche se potrebbero avere un po ‘più di “overhead” iniziale.

Eccezioni: – come guida, utilizzare le eliminazioni soft per i dati di “riferimento” come utente, categoria, ecc. E le eliminazioni complesse su una tabella mirror per dati di tipo “fact”, ad esempio, cronologia transazioni.

Ri: “È sicuro?” – Dipende da cosa intendi.

Se intendi che eliminando fisicamente, impedirai a chiunque di trovare i dati cancellati , allora sì, è più o meno vero; sei più sicuro nell’eliminare fisicamente i dati sensibili che devono essere cancellati, perché significa che è permanentemente passato dal database. (Tuttavia, rendersi conto che potrebbero esserci altre copie dei dati in questione, come in un backup, o il registro delle transazioni, o una versione registrata in transito, ad esempio uno sniffer di pacchetti – solo perché si elimina dal database non garantire che non sia stato salvato altrove.)

Se vuoi dire che, facendo una cancellazione logica, i tuoi dati sono più sicuri perché non perderai mai alcun dato , è vero anche questo. Questo è utile per gli scenari di controllo; Tendo a progettare in questo modo perché ammette il fatto fondamentale che una volta generati dati, non andrà mai veramente via (specialmente se mai avesse la capacità di essere, per esempio, memorizzato in cache da un motore di ricerca su Internet). Ovviamente, un vero scenario di audit richiede che non solo le cancellazioni siano logiche, ma che vengano registrati anche gli aggiornamenti, insieme al tempo della modifica e all’attore che ha apportato la modifica.

Se vuoi dire che i dati non cadranno nelle mani di nessuno che non dovrebbe vederlo, allora è totalmente all’altezza della tua applicazione e della sua struttura di sicurezza. A tale riguardo, l’eliminazione logica non è più o meno sicura di qualsiasi altra cosa nel tuo database.

Io di solito uso cancellazioni logiche – trovo che funzionano bene anche quando si archiviano in modo intermittente i dati “cancellati” in una tabella archiviata (che può essere cercata se necessario) senza avere alcuna possibilità di influenzare le prestazioni dell’applicazione.

Funziona bene perché hai ancora i dati se sei mai stato controllato. Se lo elimini fisicamente, è sparito !

Sono un grande fan dell’eliminazione logica, specialmente per un’applicazione Line of Business o nel contesto di account utente. Le mie ragioni sono semplici: spesso non voglio che un utente sia più in grado di utilizzare il sistema (quindi l’account viene contrassegnato come cancellato), ma se cancellassimo l’utente, perderemmo tutto il loro lavoro e così via.

Un altro scenario comune è che gli utenti potrebbero essere ricreati un po ‘dopo essere stati eliminati. È un’esperienza molto più piacevole per l’utente avere tutti i propri dati presenti com’erano prima di essere eliminati, piuttosto che doverli ricreare.

Di solito penso di eliminare gli utenti più “sospendendoli” indefinitamente. Non sai mai quando avranno legittimamente bisogno di tornare.

Cancellazioni logiche se sono difficili sull’integrità referenziale.

È giusto pensare quando c’è un aspetto temporale dei dati della tabella (sono validi FROM_DATE – TO_DATE).

Altrimenti sposta i dati in una tabella di controllo ed elimina il record.

Il lato positivo:

È il modo più semplice per eseguire il rollback (se ansible).

È facile vedere quale fosse lo stato in un momento specifico.

È abbastanza normale nei casi in cui si desidera conservare una cronologia di qualcosa (ad esempio, account utente come @Jon Dewees cita). Ed è sicuramente una grande idea se c’è una forte possibilità che gli utenti chiedono di annullare la cancellazione.

Se sei preoccupato della logica di filtrare i record eliminati dalle tue query che si complicano e complicano le tue query, puoi semplicemente creare viste che fanno il filtro per te e utilizzare le query a tale scopo. Impedirà la fuoriuscita di questi record nelle soluzioni di segnalazione e così via.

Sono fortemente in disaccordo con l’eliminazione logica perché sei esposto a molti errori.

Prima di tutto le query, ogni query deve fare attenzione al campo IsDeleted e la possibilità di errore diventa più alta con query complesse.

Secondo la performance: immagina una tabella con 100.000 rec con solo 3 attivi, ora moltiplica questo numero per le tabelle del tuo database; un altro problema di prestazioni è un ansible conflitto con nuovi record con vecchi (record cancellati).

L’unico vantaggio che vedo è la cronologia dei record, ma ci sono altri metodi per raggiungere questo risultato, ad esempio è ansible creare una tabella di registrazione in cui è ansible salvare informazioni: TableName,OldValues,NewValues,Date,User,[..] dove *Values possono essere varchar e scrivere i dettagli in questo campo nome campo fieldname : value ; [..] o memorizzare le informazioni come xml .

Tutto questo può essere ottenuto tramite codice o trigger, ma tu sei solo UN tavolo con tutta la tua storia. Un’altra opzione è vedere se il motore di database specificato è il supporto nativo per la modifica del tracciamento, ad esempio nel database di SQL Server ci sono le modifiche ai dati di traccia SQL.

Ci sono requisiti oltre alla progettazione del sistema che devono essere risolti. Qual è il requisito legale o statutario nella conservazione dei registri? A seconda di cosa sono correlate le righe, potrebbe esserci un obbligo legale che i dati vengano conservati per un certo periodo di tempo dopo che è stato “sospeso”.

D’altra parte, il requisito potrebbe essere che una volta che il record è “cancellato”, viene cancellato in modo vero e irrevocabile. Prima di prendere una decisione, parla con i tuoi stakeholder.

Non consentono al database di funzionare come dovrebbe rendere inutilizzabili funzionalità come la funzionalità a cascata.

Per cose semplici come inserti, nel caso di reinserimento, il codice dietro di esso raddoppia.

Non puoi semplicemente inserire, ma devi controllare un’esistenza e inserirla se non esiste prima o aggiornare il flag di cancellazione se lo fa mentre aggiorna anche tutte le altre colonne ai nuovi valori. Questo è visto come un aggiornamento del log delle transazioni del database e non un nuovo inserimento che causa log di verifica inaccurati.

Causano problemi di prestazioni perché le tabelle si riempiono di dati ridondanti. Gioca con l’indicizzazione soprattutto con l’unicità.

Non sono un grande fan delle eliminazioni logiche.

Le app mobili che dipendono dalla sincronizzazione potrebbero imporre l’uso dell’eliminazione logica piuttosto che fisica: un server deve essere in grado di indicare al client che un record è stato (contrassegnato come) cancellato e ciò potrebbe non essere ansible se i record fossero fisicamente cancellati.

Ho usato soft-delete, solo per conservare vecchi record. Mi sono reso conto che gli utenti non si preoccupano di visualizzare vecchi record tutte le volte che pensavo. Se gli utenti desiderano visualizzare i vecchi record, possono semplicemente visualizzare dall’archivio o dalla tabella di controllo, giusto? Quindi, qual è il vantaggio di soft-delete? Porta solo a una dichiarazione di query più complessa, ecc.

Di seguito sono le cose che ho implementato, prima ho deciso di non-soft-delete più:

  1. implementare audit, per registrare tutte le attività (aggiungere, modificare, eliminare). Assicurati che non ci sia alcuna chiave esterna collegata alla verifica e assicurati che questa tabella sia protetta e che nessuno possa cancellare ad eccezione degli amministratori.

  2. identificare quali tabelle sono considerate “tabella transazionale”, che molto probabilmente sarà conservata per molto tempo e molto probabilmente l’utente potrebbe voler visualizzare i record o i rapporti passati. Per esempio; transazione d’acquisto. Questa tabella non dovrebbe solo mantenere l’id della tabella master (come dept-id), ma anche conservare le informazioni aggiuntive come il nome come riferimento (come nome-dept), o qualsiasi altro campo necessario per la segnalazione.

  3. Implementare il record “attivo / inattivo” o “abilita / disabilita” o “nascondi / mostra” della tabella master. Quindi, invece di cancellare record, l’utente può disabilitare / distriggersre il record principale. È molto più sicuro in questo modo.

Solo l’opinione dei miei due centesimi.

Quasi sempre li elimina delicatamente e qui i miei 2 centesimi:

  • puoi ripristinare i dati cancellati se un cliente ti chiede di farlo. Clienti più soddisfatti con eliminazioni soft. Il ripristino di dati specifici dai backup è complesso
  • il controllo di isdeleted ovunque non è un problema, è comunque necessario verificare l’ isdeleted userid (se il database contiene dati di più utenti). È ansible applicare il controllo per codice, posizionando questi due controlli su una funzione separata (o utilizzare le viste)
  • cancellazione elegante. Gli utenti o i processi che si occupano di contenuti cancellati continueranno a “vederli” fino a quando non raggiungeranno il prossimo aggiornamento. Questa è una caratteristica molto desiderabile quando un processo elabora alcuni dati che vengono cancellati improvvisamente
  • sincronizzazione: se hai bisogno di progettare un meccanismo di sincronizzazione tra un database e le app mobili, troverai le eliminazioni soft così meno dolorose. Fondamentalmente si evita di sincronizzare i paradossi spostando il problema da un pazzo ADD / UPDATE / DELETE a un AGGIORNAMENTO / AGGIORNAMENTO più semplice

Soft Delete è una pratica di programmazione che viene seguita nella maggior parte delle applicazioni quando i dati sono più rilevanti. Si consideri un caso di applicazione finanziaria in cui una cancellazione per errore dell’utente finale può essere fatale. Questo è il caso in cui l’eliminazione soft diventa rilevante. In soft delete, l’utente non sta effettivamente cancellando i dati dal record, ma viene contrassegnato come IsDeleted su true (Per convenzione normale).

In EF 6.xo EF 7 in poi Softdelete viene aggiunto come attributo, ma per ora dobbiamo creare un attributo personalizzato.

Consiglio vivamente SoftDelete in una progettazione di database ed è una buona convenzione per la pratica di programmazione.

Bene! Come tutti hanno detto, dipende dalla situazione.

Se hai un indice su una colonna come UserName o EmailID – e non ti aspetti mai lo stesso UserName o EmailID da utilizzare di nuovo; puoi andare con un soft delete.

Detto questo, controlla sempre se l’operazione SELECT utilizza la chiave primaria. Se la tua istruzione SELECT utilizza una chiave primaria, aggiungere una bandiera con la clausola WHERE non farebbe molta differenza. Facciamo un esempio (Pseudo):

Utenti della tabella (UserID [chiave primaria], EmailID, IsDeleted)

SELECT * FROM Utenti dove UserID = 123456 e IsDeleted = 0

Questa query non farà alcuna differenza in termini di prestazioni poiché la colonna UserID ha una chiave primaria. Inizialmente eseguirà la scansione della tabella in base a PK e quindi eseguirà la condizione successiva.

Casi in cui le eliminazioni software non possono funzionare affatto:

Iscriviti in quasi tutti i siti web e prendi EmailID come identificazione unica. Sappiamo molto bene, una volta che un EmailID viene utilizzato su un sito web come Facebook, G +, non può essere utilizzato da nessun altro.

Arriva un giorno in cui l’utente vuole cancellare il suo profilo dal sito web. Ora, se si effettua una cancellazione logica, quell’utente non sarà in grado di registrarsi mai più. Inoltre, la registrazione di nuovo utilizzando lo stesso EmailID non significherebbe ripristinare l’intera cronologia. Tutti sanno che la cancellazione significa cancellazione. In tali scenari, dobbiamo fare una cancellazione fisica. Ma per mantenere l’intera storia dell’account, dovremmo sempre archiviare tali record nelle tabelle di archivio o nelle tabelle eliminate.

Sì, in situazioni in cui abbiamo molti tavoli stranieri, la gestione è piuttosto ingombrante.

Inoltre, tieni presente che le eliminazioni soft / logiche aumenteranno le dimensioni della tabella, quindi la dimensione dell’indice.

Per rispondere al commento di Tohid, abbiamo affrontato lo stesso problema in cui volevamo persistere nella cronologia dei record e inoltre non eravamo sicuri di volere o meno la colonna is_deleted .

Sto parlando della nostra implementazione Python e di un caso d’uso simile che abbiamo colpito.

Abbiamo incontrato https://github.com/kvesteri/sqlalchemy-continuum che è un modo semplice per ottenere la tabella delle versioni per la tabella corrispondente. Linee minime di codice e cattura cronologia per aggiungere, eliminare e aggiornare.

Questo serve più della semplice colonna is_deleted . Puoi sempre eseguire il backref della tabella delle versioni per verificare cosa è successo con questa voce. Se la voce è stata cancellata, aggiornata o aggiunta.

In questo modo non avevamo bisogno di avere la colonna is_deleted e la nostra funzione di cancellazione era piuttosto banale. In questo modo, inoltre, non è necessario ricordare di contrassegnare is_deleted=False in una qualsiasi delle nostre API.

La maggior parte del tempo è utilizzato per il softdeleting perché non vuoi esporre alcuni dati ma devi mantenerli per ragioni storiche (un prodotto potrebbe essere sospeso, quindi non vuoi nessuna nuova transazione con esso, ma devi comunque lavorare con la cronologia delle transazioni di vendita). A proposito, alcuni stanno copiando il valore delle informazioni sul prodotto nei dati della transazione di vendita invece di fare riferimento al prodotto per gestirlo.

In effetti sembra più una riformulazione per una funzione visibile / nascosta o triggers / non triggers. Perché questo è il significato di “cancellare” nel mondo degli affari. Mi piacerebbe dire che i Terminator possono eliminare le persone ma il capo li licenzia semplicemente.

Questa pratica è piuttosto comune e viene utilizzata da molte applicazioni per molte ragioni. Poiché non è l’unico modo per raggiungere questo objective, avrai migliaia di persone che dicono che è grandioso o cazzate ed entrambi hanno argomenti abbastanza buoni.

Da un punto di vista della sicurezza, SoftDelete non sostituirà il lavoro di Audit e non sostituirà anche il lavoro di backup. Se hai paura di “inserire / eliminare tra due casi di backup”, dovresti leggere i modelli di recupero completo o collettivo. Ammetto che SoftDelete potrebbe rendere il processo di recupero più banale.

Fino a voi per conoscere le vostre esigenze.

Per dare un’alternativa, abbiamo utenti che utilizzano dispositivi remoti che si aggiornano tramite MobiLink. Se cancelliamo i record nel database del server, quei record non vengono mai marcati cancellati nei database dei clienti.

Quindi facciamo entrambi. Lavoriamo con i nostri clienti per determinare quanto tempo desiderano essere in grado di recuperare i dati. Ad esempio, in genere i clienti e i prodotti sono attivi fino a quando il nostro cliente non dice che devono essere eliminati, ma la cronologia delle vendite viene conservata per 13 mesi e quindi viene eliminata automaticamente. Il cliente potrebbe voler mantenere clienti e prodotti eliminati per due mesi, ma conserva la cronologia per sei mesi.

Quindi eseguiamo uno script durante la notte che contrassegna le cose logicamente cancellate in base a questi parametri e poi due / sei mesi dopo, qualsiasi cosa contrassegnata logicamente cancellata oggi verrà cancellata.

Abbiamo meno sicurezza dei dati che avere enormi database su un dispositivo client con memoria limitata, come uno smartphone. Un cliente che ordina 200 prodotti due volte alla settimana per quattro anni avrà oltre 81.000 righe di storia, di cui al 75% il cliente non si cura se vede.

Tutto dipende dal caso d’uso del sistema e dai suoi dati.

Ad esempio, se stai parlando di un sistema governativo regolamentato (ad esempio un sistema presso un’azienda farmaceutica che è considerato parte del sistema di qualità e deve seguire le linee guida FDA per i record elettronici), allora hai fatto meglio a non fare cancellazioni difficili! Un auditor della FDA può entrare e chiedere tutti i record nel sistema relativi al numero di prodotto ABC-123, e tutti i dati migliori saranno disponibili. Se il proprietario del processo aziendale dichiara che il sistema non dovrebbe consentire a nessuno di utilizzare il numero di prodotto ABC-123 sui nuovi record in futuro, utilizzare il metodo di eliminazione software invece di renderlo “inattivo” all’interno del sistema, mantenendo comunque i dati storici.

Tuttavia, forse il tuo sistema e i suoi dati hanno un caso d’uso come “tenere traccia del tempo al Polo Nord”. Forse prendi letture della temperatura una volta ogni ora, e alla fine della giornata aggrega una media giornaliera. Forse i dati orari non saranno più utilizzati dopo l’aggregazione e eliminerai le letture orarie dopo aver creato l’aggregato. (Questo è un esempio inventato, banale.)

Il punto è che tutto dipende dal caso d’uso del sistema e dai suoi dati, e non una decisione da prendere puramente da un punto di vista tecnologico.

È il 2018 e un grosso svantaggio di Soft Delete è:

Conformità GDPR

Probabilmente la tua applicazione non è conforms a GDPR se fai delle eliminazioni soft su tutto ciò che è considerato dati personali . [ 1 ] [ 2 ]

Inoltre, tieni presente che, anche se la tua azienda non si trova all’interno dell’UE, finché hai a che fare con dati di aziende, residenti o cittadini dell’UE, dovrai rispettare il GDPR. [ 3 ]