La mancata eliminazione creerà una nuova classe di bug per tutte le query future. Non dimenticare che la scrittura di query viene spesso eseguita da utenti esperti (cioè professionisti non IT) e sviluppatori junior. Quindi ora ogni tabella che ha dati non validi contrassegnati solo da un flag BIT attivo avrà bisogno di un AND aggiuntivo nella clausola WHERE per ogni query da ora fino a per sempre. Questo aiuterà gli utenti a cadere nella fossa del fallimento invece che nella fossa del successo. Tuttavia, ti consiglio vivamente di implementare comunque questi sistemi di flag perché senza una cattiva progettazione, non è necessario che gli sviluppatori di manutenzione risolvano i numerosi bug che creerà.
Quanto è prezioso avere dati storici nella tabella? Se l'azienda è lungimirante, avere vecchi dati nelle tabelle può essere solo un peso, causa problemi durante la creazione di vincoli (tutti i vincoli dovranno essere modificati per escludere i dati che vorresti non fossero presenti). La garanzia della qualità dei dati è complicata dal dover reidentificare continuamente ciò che è "vecchie stronzate che abbiamo paura di eliminare ma non vogliamo mai usare o aggiornare di nuovo" e nuove cose a cui teniamo.
È stato cancellato perché è stato un errore? Se la riga corrisponde a un'entità nella vita reale, forse è interessante mantenere e impostare una bandiera "vaporizzato", "morto", "lasciato l'edificio". Se hai inserito accidentalmente una riga che non corrisponde a nessuna entità nella vita reale, un DELETE non è una brutta cosa. È importante tenere nella tavola dei clienti clienti immaginari che non sono mai esistiti?
E infine, la personalità gioca un ruolo importante. Anche le persone possono essere packrat con i dati. Se un DBA conserva tutti i suoi giornali di 30 anni fa e non gli piace eliminare i dati, forse dovrebbe assicurarsi di prendere decisioni di progettazione dei dati basate sui meriti e non su una preferenza personale irrilevante.
