Saya tidak yakin ada satu "pendekatan terbaik", ada begitu banyak variabel yang perlu dipertimbangkan, termasuk seberapa jauh Anda berada di jalur pengembangan.
Setelah melalui solusi audit berbasis kode dan pemicu db, saya telah mencantumkan beberapa komentar di bawah ini; Saya harap Anda dapat melihat di mana Anda berada sekarang (dalam hal pengembangan) dapat memengaruhi masalah ini:
- Jika Anda perlu memetakan pengguna yang mengubah data (yang biasanya Anda lakukan), pemicu db perlu mendapatkan informasi ini. Bukan tidak mungkin, tetapi lebih banyak pekerjaan dan beberapa cara untuk mendekati ini (pengguna db mengeksekusi kueri, kolom pengguna umum di setiap tabel, dll.)
- Jika Anda menggunakan pemicu db dan Anda mengandalkan jumlah baris yang terpengaruh yang dikembalikan dari kueri, maka pemicu audit Anda harus menonaktifkannya, atau kode yang ada dimodifikasi untuk memperhitungkannya.
- Pemicu db IMHO menawarkan lebih banyak keamanan, dan menawarkan jalur yang lebih mudah untuk mengaudit otomatisasi, namun mereka tidak mudah, karena siapa pun dengan akses yang sesuai dapat menonaktifkan pemicu, memodifikasi data, dan kemudian mengaktifkannya kembali. Dengan kata lain, pastikan hak akses keamanan db Anda ketat.
- Memiliki satu tabel untuk riwayat bukanlah cara yang buruk, meskipun Anda akan memiliki lebih banyak pekerjaan yang harus dilakukan (dan data untuk disimpan) jika Anda mengaudit riwayat untuk beberapa tabel, terutama dalam hal merekonstruksi jejak audit. Anda juga harus mempertimbangkan masalah penguncian jika ada banyak tabel yang mencoba menulis ke satu tabel audit.
- Memiliki tabel riwayat audit untuk setiap tabel adalah opsi lain. Anda hanya perlu setiap kolom dalam tabel audit menjadi nullable, serta menyimpan tanggal dan waktu tindakan (masukkan/perbarui/hapus) dan pengguna yang terkait dengan tindakan tersebut.
- Jika Anda menggunakan opsi tabel tunggal, kecuali jika Anda memiliki banyak waktu untuk dihabiskan untuk hal ini, jangan terlalu senang mencoba mengaudit hanya pada pembaruan atau penghapusan, meskipun mungkin tergoda untuk menghindari penyisipan (karena sebagian besar aplikasi melakukan ini lebih sering daripada memperbarui atau menghapus), merekonstruksi riwayat audit membutuhkan sedikit usaha.
- Jika server atau data Anda menjangkau beberapa zona waktu, pertimbangkan untuk menggunakan jenis waktu-tanggal yang sesuai untuk dapat menyimpan dan merekonstruksi garis waktu, yaitu menyimpan tanggal peristiwa audit dalam UTC serta menyertakan offset zona waktu.
- Tabel audit ini bisa menjadi sangat besar, jadi siapkan strategi jika tabel tersebut mulai memengaruhi kinerja. Pilihan termasuk partisi tabel ke disk yang berbeda, pengarsipan, dll. Pada dasarnya pikirkan tentang ini sekarang dan bukan ketika menjadi masalah :)
