Jawaban filosofis:Basis data sub-optimal (relasional) penuh dengan anomali penyisipan, pembaruan, dan penghapusan. Ini semua menyebabkan data yang tidak konsisten, menghasilkan kualitas data yang buruk. Jika Anda tidak dapat mempercayai keakuratan data Anda, apa gunanya? Tanyakan pada diri sendiri:Apakah Anda ingin jawaban yang benar lebih lambat atau Anda ingin jawaban yang salah lebih cepat?
Sebagai masalah praktis:lakukan dengan benar sebelum Anda melakukannya dengan cepat. Kita manusia sangat buruk dalam memprediksi di mana kemacetan akan terjadi. Jadikan basis datanya hebat, ukur kinerjanya selama periode waktu yang layak, lalu putuskan apakah Anda perlu membuatnya lebih cepat. Sebelum Anda melakukan denormalisasi dan mengorbankan akurasi, coba teknik lain:bisakah Anda mendapatkan server, koneksi, driver db yang lebih cepat, dll? Mungkinkah prosedur tersimpan mempercepat? Bagaimana indeks dan faktor pengisiannya? Jika itu dan teknik kinerja dan penyetelan lainnya tidak berhasil, baru pertimbangkan denormalisasi. Kemudian ukur kinerja untuk memverifikasi bahwa Anda mendapatkan peningkatan kecepatan yang Anda "bayar". Pastikan Anda melakukan pengoptimalan, bukan pesimis.
[sunting]
J:Tentu.
- Buat cadangan.
- Buat cadangan lain ke perangkat lain.
- Buat tabel baru dengan perintah ketik "select into newtable from oldtable...". Anda harus melakukan beberapa penggabungan untuk menggabungkan tabel yang sebelumnya berbeda.
- Jatuhkan tabel lama.
- Ganti nama tabel baru.
TAPI ... pertimbangkan pendekatan yang lebih kuat:
Buat beberapa tampilan pada tabel Anda yang sepenuhnya dinormalisasi sekarang. Tampilan tersebut (tabel virtual, "jendela" pada data... tanya saya apakah Anda ingin tahu lebih banyak tentang topik ini) akan memiliki kueri pendefinisian yang sama seperti langkah ketiga di atas. Saat Anda menulis aplikasi atau logika lapisan DB, gunakan tampilan (setidaknya untuk akses baca; tampilan yang dapat diperbarui adalah... yah, menarik). Kemudian jika Anda melakukan denormalisasi nanti, buat tabel baru seperti di atas, jatuhkan tampilan, ganti nama tabel dasar baru apa pun tampilannya. Aplikasi/lapisan DB Anda tidak akan tahu bedanya.
Sebenarnya ada lebih dari ini dalam praktiknya, tetapi ini akan membantu Anda memulai.
