Una risposta filosofica:i database non ottimali (relazionali) sono pieni di anomalie di inserimento, aggiornamento ed eliminazione. Tutti questi portano a dati incoerenti, con conseguente scarsa qualità dei dati. Se non puoi fidarti dell'accuratezza dei tuoi dati, a che serve? Chiediti questo:vuoi le risposte giuste più lentamente o vuoi le risposte sbagliate più velocemente?
In pratica:fallo bene prima di ottenerlo velocemente. Noi umani siamo molto pessimi nel prevedere dove si verificheranno i colli di bottiglia. Rendi ottimo il database, misura le prestazioni in un periodo di tempo decente, quindi decidi se è necessario renderlo più veloce. Prima di denormalizzare e sacrificare l'accuratezza, prova altre tecniche:puoi ottenere un server, una connessione, un driver db più veloci, ecc? Le stored procedure potrebbero accelerare le cose? Come sono gli indici e i loro fattori di riempimento? Se quelle e altre tecniche di esecuzione e messa a punto non funzionano, solo allora prendi in considerazione la denormalizzazione. Quindi misura le prestazioni per verificare di aver ottenuto l'aumento di velocità per cui hai "pagato". Assicurati di eseguire l'ottimizzazione, non la pessimizzazione.
[modifica]
R:Certo.
- Fai un backup.
- Esegui un altro backup su un dispositivo diverso.
- Crea nuove tabelle con i comandi di tipo "select into newtable from oldtable...". Dovrai eseguire alcune unioni per combinare tabelle precedentemente distinte.
- Lascia le vecchie tabelle.
- Rinomina le nuove tabelle.
MA ... considera un approccio più solido:
Crea subito alcune visualizzazioni sulle tue tabelle completamente normalizzate. Quelle viste (tabelle virtuali, "finestre" sui dati... chiedimi se vuoi saperne di più su questo argomento) avrebbero la stessa query di definizione del passaggio tre sopra. Quando scrivi la tua applicazione o la logica del livello DB, usa le viste (almeno per l'accesso in lettura; le viste aggiornabili sono... beh, interessanti). Quindi, se denormalizzi in seguito, crea una nuova tabella come sopra, rilascia la vista, rinomina la nuova tabella di base qualunque fosse la vista. La tua applicazione/livello DB non riconoscerà la differenza.
In pratica c'è di più in questo, ma questo dovrebbe farti iniziare.
