Jawaban oleh Marjan Venema secara teknis valid dan harus diikuti jika memungkinkan. Sayangnya, Marjan menjawab dari sudut pandang seorang ahli teori , atau seorang administrator basis data purist yang suka membuat hal-hal bersih. Dalam praktiknya, terkadang kendala bisnis membuat tidak mungkin melakukan hal-hal dengan cara yang bersih.
Bayangkan kasus berikut:
Ada bug dalam produk perangkat lunak yang menyebabkannya berhenti berfungsi ketika ia mendeteksi apa yang dianggapnya sebagai beberapa ketidakkonsistenan data dalam basis data,
Semua pengembang yang berpotensi memperbaiki bug di aplikasi tidak dapat dijangkau,
Perusahaan saat ini kehilangan ribuan dolar per jam (katakanlah $ 6.000, yang berarti $ 100 per menit),
Bug mempengaruhi beberapa tabel, salah satunya sangat besar, dan hanya menyangkut data itu sendiri, bukan skema,
Untuk menghindari bug, Anda harus bereksperimen sedikit dengan data, yang melibatkan menghapus dan mengubahnya,
Basis datanya besar dan butuh tiga jam untuk mengambil atau mengembalikan cadangan,
Cadangan lengkap terakhir diambil tiga minggu lalu; ada juga cadangan inkremental harian, dan cadangan inkremental harian terakhir dilakukan 14 jam yang lalu,
Cadangan basis data dianggap andal; mereka sangat diuji, termasuk baru-baru ini,
Kehilangan 14 jam data tidak dapat diterima, tetapi hilangnya satu atau dua jam data adalah,
Lingkungan pementasan terakhir digunakan enam bulan lalu; sepertinya tidak up to date, dan mungkin butuh berjam-jam mengaturnya,
Basis datanya adalah Microsoft SQL Server 2008 Enterprise.
Cara bersih untuk melakukan sesuatu adalah dengan:
Kembalikan cadangan dalam lingkungan pementasan,
Eksperimen di sana,
Periksa skrip akhir dua kali,
Jalankan skrip di server produksi.
Hanya langkah pertama akan dikenakan biaya $ 18.000 untuk perusahaan Anda. Risiko ini cukup rendah jika Anda melakukan langkah ketiga dengan sempurna, tetapi karena Anda bekerja di bawah tekanan yang ekstrem, risikonya akan jauh lebih tinggi. Anda mungkin berakhir dengan skrip yang bekerja dengan sangat baik dalam pementasan, lalu mengacaukan basis data produksi.
Sebaliknya, Anda bisa melakukan seperti ini:
Buat snapshot (Microsoft SQL Server mendukungnya, dan perlu beberapa detik untuk mengembalikan (dan tidak membuat apa pun) snapshot dari database yang memerlukan satu jam untuk cadangan; Saya membayangkan bahwa produk database lain juga mendukung snapshot),
Eksperimen langsung pada basis data produksi, kembali ke snapshot jika terjadi kesalahan.
Sementara seorang purist akan memperbaiki database dengan cara yang bersih dan masih memiliki risiko untuk mengacaukan segalanya mengingat tekanan waktu sambil menghabiskan lebih dari $ 20.000 dari perusahaannya, seorang administrator database yang memperhitungkan kendala bisnis akan memperbaiki database dengan cara yang akan meminimalkan risiko (berkat foto) saat melakukannya dengan cepat.
Kesimpulan
Saya sendiri seorang purist, dan saya benci melakukan sesuatu dengan cara yang tidak bersih. Sebagai seorang pengembang, saya memperbaiki kode yang saya modifikasi, saya berkomentar bagian-bagian sulit yang tidak dapat di refactored, saya unit-test basis kode dan saya melakukan tinjauan kode. Tetapi saya juga mempertimbangkan keadaan di mana Anda melakukan sesuatu dengan bersih dan keesokan harinya Anda dipecat, atau Anda meminimalkan risiko dan dampak finansial dengan melakukan peretasan cepat yang berfungsi.
Jika beberapa pria IT ingin melakukan sesuatu dengan bersih hanya demi kebersihan sementara itu menyebabkan ribuan dolar kerugian bagi perusahaan, pria IT ini memiliki kesalahpahaman yang mendalam tentang pekerjaannya.