Denormalizzare i dati o la chiave a più colonne?

Question

Sto cercando di emettere un giudizio sull'implementazione di un piccolo database SQL Server '08.

Sto traducendo un file di testo di output di un database di file flat da un vecchio sistema COBOL al suddetto database di SQL Server. Si tratta di un database di prestiti immobiliari e immobiliari, che può essere identificato in modo univoco dalla combinazione di un ID prestatore (un numero di sette cifre), un numero di conto bancario (15 cifre) e "suffisso del conto"; (due cifre).

Confesso di essere abbastanza ingenuo quando si tratta di amministrazione del database (a dire il vero, non l'ho ancora fatto fino alla mia posizione attuale) e sto cercando di determinare quale dei due approcci sia la mia migliore opzione per l'implementazione di una chiave che indicizzerà in diverse altre tabelle:

1) Identifica ciascun prestito utilizzando una chiave a tre colonne dei valori sopra indicati, oppure
2) Denormalizzare i dati implementando una "chiave" colonna che è una stringa di 24 caratteri che combina i tre valori.

La denormalizzazione è brutta, scontata, ma non posso prevedere che si verifichino anomalie di aggiornamento, poiché i prestiti non possono essere trasferiti avanti e indietro tra le banche o modificare il loro suffisso. Una modifica di questi valori è garantita per essere un account diverso.

Una chiave composta è più elegante, ma ho letto alcuni trattati che suggeriscono che è una cosa negativa.

Quindi, quale opzione è probabilmente una scelta migliore e, soprattutto, perché?

Answer 1

Vorrei usare una chiave surrogata generata automaticamente e quindi inserire un indice univoco sulla chiave naturale. In questo modo se la chiave naturale cambia (e potrebbe dire se una banca è stata acquistata da un'altra banca), allora deve cambiare solo in un posto. La cosa più importante nell'uso di una chiave surrogata è quella di garantire l'unicità della chiave naturale se uno si allontana e l'indice univoco lo farà.

Answer 2

Se si tratta di dati di riferimento che non verranno aggiornati spesso, l'utilizzo della chiave multiparte dovrebbe andare bene.

Se si tratta di dati transazionali a traffico elevato, aggiungere una chiave surrogata (identità int, chiave primaria in cluster) e rendere la chiave in tre parti una chiave alternativa.

Non suggerirei di implementare l'opzione 2.

Answer 3

Suggerirei semplicemente di usare una chiave surrogata numerica a incremento automatico. Perché dovrebbe essere un mashup delle altre tre "chiavi"? colonne?