Quali sono le migliori pratiche per ritirare le colonne obsolete del database? [chiuso]

Se vuoi conservare i dati, allora non è obsoleto. Lascialo solo dove è. Va bene se qualche classe mappata su una tabella non mappa ogni colonna.

OK, la tua situazione è che vuoi che le vecchie righe abbiano la proprietà C ma quelle nuove no.

Questo è equivalente ad avere una relazione di ereditarietà della classe

class All
{
    string A;
    string B;
}

class Old : All
{
    string C;
}

class New : All
{
    string D;
}

che rappresenteresti sul database con tre tabelle con relazioni 1 a 1

table All
    id varchar
    A varchar
    B varchar

table Old
    id varchar
    C  varchar

table New
    id varchar
    D  varchar

Quindi potresti creare uno script di migrazione per creare la nuova tabella vecchia, copiare i dati id e C e rimuovere la colonna C dalla tabella All.

Aggiornamento del codice come richiesto con il nuovo sql;

In alternativa, se hai solo bisogno di essere in grado di interrogare i vecchi dati C, potresti creare una nuova tabella di archivio con A, B, C copia tutti i dati e rimuovere la colonna C, aggiungi il campo D alla tua "Live" tabella

Se la memorizzazione dei dati potrebbe essere un problema, allora dividi le tabelle: chiave / A / B chiave / C chiave / D

È possibile eseguire l'accesso tramite una vista (definizione della posizione dei dati nel db) o modificando la definizione ORM.

Questo non è il più performante (è coinvolto un join), ma può presentare qualsiasi combinazione di A / B / C / D nel tempo senza cambiare la memoria e l'amplificazione sottostanti; a seconda dei tuoi reali schemi di accesso potrebbe essere sufficiente.

Potresti non essere fortunato con la possibilità di ridurre i tempi di inattività, ristrutturare le tabelle, ecc. in un sistema di produzione.

L'esecuzione dell'accesso tramite la visualizzazione consente di passare da A / B / C a A / B / C / D a A / B / D nella tabella sottostante con modifica minima e senza spostamento di dati. Una vista sarà trasparente per la logica di lettura e se il tuo dbms supporta entrambe le funzioni o le viste aggiornabili allora trasparente anche alla logica di scrittura.

Penso davvero che la tua decisione rifletterà molte delle preoccupazioni del mondo reale: 1) quali sono i tipi di dati C & D 2) i relativi volumi di dati raccolti per C / D 3) Sovrapposizione relativa dei dati C / D rispetto alle sole voci C o D 4) Disponibilità e durata della finestra di fermo / manutenzione 5) Supporto DBMS per visualizzazioni aggiornabili 6) La desiderabilità di mantenere i dettagli della struttura fisica db nell'ORM rendendolo trasparente presentando tramite viste / funzioni nel db (dove è lo stesso per tutti gli accessi alle applicazioni, non solo quello corrente)

La mia risposta preferita per i tipi di dati grandi / complessi per (1), poca sovrapposizione per (3) e tempi di inattività minimi per (4), idealmente con un buon supporto di dbms in (5) e più applicazioni che accedono ai dati in (6)

Ma non c'è giusto / sbagliato per molte alternative: - Inizia con A / B / C, poi aggiungi D, aggiustando ORM, ancora dopo rilascia la colonna C - Inizia con A / B / C / D & ignora i null eccetera. Penso, considera la tua soluzione & quello che sai del suo scopo / ciclo di vita, fare qualche modellazione di dimensioni / volume e amp; aspettati di cambiare le cose in seguito, poiché non tutto cambierà come previsto.

Rimozione di riferimenti e amp; orfano i dati è un'opzione a basso rischio.

Ci sono sempre possibili usi "backdoor" sconosciuti dei dati che possono o non possono essere importanti da esporre rimuovendo la colonna.

A seconda del contenuto della colonna C potrebbe esserci un piccolo problema di prestazioni quando il DB internamente esegue scansioni complete della tabella o tenta di trascinare l'intera tabella in memoria durante i join se l'ottimizzatore lo vede più efficiente dell'uso degli indici.

Le applicazioni potrebbero leggere l'intera tabella più volte che non le colonne selezionate, ma se stai utilizzando un ORM esclusivamente, è improbabile.

Molte cose da considerare qui, ma potresti prendere in considerazione l'aggiunta di una vista per sovrapporre la tabella piuttosto che apportare modifiche direttamente alla tabella. In questo modo, è solo la vista che deve cambiare.

Non conosco l'ORM di Django, ma potrebbe essere una possibilità.

• Hai una tabella A con le colonne a, b, c.
• Crea una nuova tabella B con le colonne a, b, d.
• Migrazione dei dati nella Tabella B.
• Sposta le tue chiavi esterne nella tabella A nella tabella B.

Ora puoi utilizzare la Tabella B e hai ancora i tuoi vecchi dati come riferimento.