Dovresti SICURAMENTE introdurre un surrogato INT IDENTITY() chiave primaria!!INT ti dà già potenzialmente fino a 2 miliardi di righe - non è abbastanza??
Questa chiave primaria/chiave in cluster su SQL Server avrà una dimensione massima di 64 byte (invece di 4, per un INT), il che renderà il tuo indice cluster E tutto il tuo indice non cluster gonfio oltre il riconoscimento. L'intera chiave di clustering (tutte le tue 8 colonne) sarà inclusa in ogni singola pagina di ogni singolo indice non in cluster su quella tabella, sprecando sicuramente molto spazio.
Quindi, su una determinata tabella di indice, avresti fino a 16 volte più voci con una chiave cluster INT surrogata, il che significa molto meno I/O, molto meno tempo sprecato a leggere le pagine dell'indice.
E immagina di provare a stabilire una relazione di chiave esterna con quella tabella... qualsiasi tabella figlio dovrebbe avere tutte le 8 colonne della tua chiave primaria come colonne di chiave esterna e specifica tutte e 8 le colonne in ogni join:che incubo!!
A 78 milioni di righe, anche solo la modifica della chiave di clustering su INT IDENTITY ti farà risparmiare fino a 60 byte per riga, che da solo risulterebbe essere fino a 4 GByte di spazio su disco (e l'utilizzo della RAM nel tuo server). E non si comincia nemmeno a calcolare il risparmio sugli indici non cluster....
E, naturalmente, sì, cambierei anche VARCHAR(10) in INT o BIGINT - se è un numero, rendi il tipo di campo numerico - non ha senso lasciarlo su VARCHAR(10), davvero. Ma questo da solo non farà un'enorme differenza in termini di velocità o prestazioni:rende molto più semplice lavorare con i dati (non è necessario passare sempre a tipi numerici quando, ad esempio, si confrontano valori e così via).
Marco
