Eliminazione di una colonna da una tabella in produzione

Abbiamo una situazione in cui è necessario modificare la relazione tra 2 tabelle da m: 1 a m: n .

Quindi, dobbiamo creare una tabella di riferimenti incrociati tra queste due tabelle.

Dopo aver migrato tutti i dati esistenti dalla tabella "figlio" nella tabella dei riferimenti incrociati, sarebbe una cattiva idea eliminare la colonna chiave esterna originale nella tabella figlio?

Se lo lasciamo lì, abbiamo fondamentalmente un debito tecnico. Ma non sono un dba e non ho una buona comprensione delle implicazioni dell'eliminazione di una colonna da una tabella. (So ​​che è possibile, ma è una cattiva idea? Il mio database mi odierà per questo?)

Grazie

Senza conoscere tutta la struttura dei tuoi tavoli sono limitato nei miei consigli. Tuttavia, no, il tuo database non traccia la tua morte se rimuovi una colonna nelle seguenti circostanze (non esaustivo):

1. Si utilizza ancora una chiave di database per mappare le dimensioni.
2. I tuoi nuovi indici su questa nuova tabella delle dimensioni coprono correttamente gli indici quando dovrebbero essere.
3. Gestisci questo numero di indici in modo da non sovraccaricare Inserisci / Aggiornamenti

Il tuo nuovo design ha due tabelle dimensionali e una tabella dei fatti

• Questo è il motivo per cui è passato da m: 1 a m: n con una tabella "riferimenti incrociati". Questa la chiamiamo un'altra dimensione.

Il design ha effettivamente implementato la normalizzazione per raggiungere questo obiettivo

• Rimuovendo una dipendenza, il tuo team sarà meglio attrezzato per recuperare i fatti che possono trasformare il modo in cui i tuoi dati vengono elaborati in modo più significativo.

Nota su dimensioni e fatti

• Dimensioni per il contesto descrittivo

Le dimensioni forniscono il contesto "chi, cosa, dove, quando, perché e come" che circonda un evento di processo aziendale. Le tabelle dimensionali contengono gli attributi descrittivi utilizzati dalle applicazioni BI per filtrare e raggruppare i fatti. Tenendo ben presente la trama di una tabella dei fatti, è possibile identificare tutte le dimensioni possibili.

Quando possibile, una dimensione dovrebbe essere valutata singolarmente quando associata a una determinata riga di fatti . Le tabelle dimensionali sono talvolta chiamate "anima" del data warehouse perché contengono i punti di ingresso e le etichette descrittive che consentono al sistema DW / BI di essere sfruttato per l'analisi aziendale. Una quantità sproporzionata di sforzi viene posta nella governance dei dati e nello sviluppo delle tabelle dimensionali perché sono i driver dell'esperienza BI dell'utente.

• Fatti per le misurazioni

I fatti sono le misurazioni che derivano da un evento di processo aziendale e sono quasi sempre numeriche. Una riga della tabella dei fatti singola ha una relazione uno a uno con un evento di misurazione come descritto dal grano della tabella dei fatti . Quindi una tabella dei fatti corrisponde a un evento fisico osservabile e non alle esigenze di un particolare rapporto . All'interno di una tabella dei fatti, sono consentiti solo fatti coerenti con il grano dichiarato . Ad esempio, in una transazione di vendita al dettaglio, la quantità di un prodotto venduto e il suo prezzo esteso sono buoni fatti, mentre lo stipendio del gestore del negozio non è consentito.

Tecniche di modellazione dimensionale Kimball

Il mio suggerimento è che il team di progettazione dovrebbe sapere che è meglio applicare le regole nel database, a meno che non danneggi le prestazioni. Tuttavia, non conosco le dimensioni o la quantificazione delle tue dichiarazioni DDL per rispondere pienamente a questa domanda.

Ma stai certo che questo dovrebbe essere un cambiamento positivo per il tuo sistema in quanto ora SQL Server non dovrà esaminare tutti quei dati extra per recuperare ciò che conta davvero.

So che è possibile, ma è una cattiva idea? Il mio database mi odierà per questo?

Non posso parlare per il tuo database ma ti oderei per questo :-)

La colonna legacy conterrà dati ridondanti dopo la modifica. Ciò potrebbe causare dati in conflitto se la vecchia colonna e la nuova tabella xrif non vengono mantenute coerentemente tra loro. Considera che gli sviluppatori che non hanno familiarità con il debito tecnico potrebbero logicamente corrompere il database.

Sono difficile pensare a un motivo per cui non si dovrebbero rimuovere la colonna e la relazione legacy. Ciò garantirà anche che tutto il codice dipendente sia stato correttamente modificato.