Per quello che riguarda la normalizzazione, avevo capito male. Pensavo
che tu avessi continui INSERT in questa tabella e che, per ogni
INSERT, nei 16 campi fissi inserivi sempre lo stesso dato, mentre
cambiavano solo gli altri 10. In quel caso il db andava normalizzato
in quanto vi era ripetizione della stessa informazione su piu' righe.
Ma non e' il tuo caso: se stavolta ho capito bene :) tu hai una riga
in cui 16 valori sono costanti dal momento dell'INSERT mentre gli
altri 10 subiscono diversi UPDATE. Esatto?
Visto che mi chiedi di parlarne un po' in generale, questo e' un
problema che si presenta dei database distribuiti: quando si deve
trattare una mole immensa di dati, una sola macchina non ce la fa
piu', e quindi il db viene frammentato su piu' macchine. Questa
tecnica e' chiamata appunto frammentazione. Nel tuo caso puo' venire
in aiuto per aumentare le prestazioni del vacuum.
Nel tuo caso particolare, il database va rivisto utilizzando la
frammentazione verticale, che non e' ne' piu' ne' meno quello a cui tu
hai pensato: si divide la tabella originaria in due parti, separando i
16 dati che non subiscono update da quelli che li subiscono.
Ovviamente ricorda che le due tabelle risultanti devono avere entrambe
il campo chiave primaria uguale, in modo da fare poi il join (NB: un
natural join, non un inner join) per ricostruire la tabella originale.
In realta' non so se riscontrerai un gran vantaggio prestazionale, in
quanto utilizzando comunque la stessa macchina (quindi le stesse
risorse), l'unico vantaggio che mi viene in mente cosi' su due piedi
e' quello che hai citato tu: il vacuum agira' solo sulla tabella degli
update che e' meno oneroso che accedere a quella completa. Di quanto
meno oneroso, non so dirtelo cosi' su due piedi. D'altro canto non so
se ti convenga (magari si'), in caso di prestazioni sempre pessime del
vacuum full, attuare qualche soluzione di load balancing (tipo
Postgres-R), bisognerebbe fare un'analisi costi/benefici, ma sto
divagando.
Dove sta la fregatura (parlando in generale di questo metodo)? Beh
anche qui ti sei gia' risposto da solo: nei JOIN. Come nel caso della
normalizzazione (e del motivo per cui si arriva quasi sempre alla
terza forma normale o al massimo alla BCNF), spezzare le tabelle in
piu' tabelle comporta fare poi dei join per ricostruirle, e di questo
costo va tenuto conto.
Quindi, concludendo, devi vedere tu se ti conviene o no. Dal punto di
vista della correttezza la soluzione a cui sei giunto va bene, anzi se
non avevi nozioni di frammentazione ecc... complimenti per l'intuito
:) Pero' devi vedere il rapporto costi/benefici.
