Apakah masuk akal untuk melakukan standarisasi termasuk tanggal yang dibuat dan bidang tanggal terakhir diperbarui pada semua tabel DB?


38

Bos saya saat ini sedang mencoba untuk menerapkan beberapa standar pengembangan untuk tim kami, jadi kami mengadakan pertemuan kemarin untuk membahas standar yang sebagian besar berjalan dengan baik sampai dia mengemukakan:

  • Semua tabel DB akan memiliki kolom CreatedDate dan LastUpdatedDate, diperbarui oleh pemicu.

Pada titik ini tim kami mengalami perpecahan pendapat; setengah dari kita berpikir bahwa melakukan ini pada semua tabel adalah sejumlah besar pekerjaan dengan sedikit manfaat (kita bekerja pada proyek anggaran tetap sehingga biaya apa pun berasal dari keuntungan perusahaan kita); bagian kedua percaya itu akan membantu dengan dukungan proyek.

Saya tegas di bekas kamp. Sementara saya menghargai bahwa beberapa kasus luar akan menyebabkan kolom tambahan untuk meningkatkan dukungan, menurut pendapat saya jumlah pekerjaan yang akan diperlukan untuk menambahkan kolom di tempat pertama, serta pemeliharaan, akan menyebabkan kita menghabiskan lebih sedikit waktu untuk lebih hal-hal penting seperti Unit- atau Load-Testing. Juga, saya cukup yakin bahwa kolom tambahan ini akan membuatnya lebih canggung untuk menggunakan ORM - mengingat bahwa kita terutama menggunakan C # dan Oracle, yang awalnya tidak terlalu suka ORM.

Jadi, pertanyaan saya ada dua:

  • Apakah saya di kamp yang benar? Saya tidak mengklaim memiliki keterampilan basis data yang terkenal di dunia, jadi ini mungkin penambahan yang mudah secara sepele tanpa efek samping yang merugikan.
  • Bagaimana Anda menghadapi situasi di mana pertemuan tentang standar berubah menjadi pertandingan slagging? Bagaimana saya bisa benar-benar menjual bahwa standar ini tidak akan membantu kami dalam jangka panjang?

Mengapa Anda mengatakan C # tidak senang ORM? Juga, menambahkan properti [insert = "false" update = "false" generate = "always"] ke pemetaan dua kolom ini di NHibernate misalnya tidak tampak canggung bagi saya, atau apakah saya kehilangan sesuatu?
Jalayn

C # + Oracle bukan ORM-happy, dan kami menemukan bahwa NHibernate terlalu berat (rupanya, saya tidak terlibat dalam sedikit investigasi perkakas). Saya mungkin menempatkan C # dan Oracle mundur dalam pertanyaan utama.
Ed James

Anda harus mempertimbangkan mengganti nama judul pertanyaan Anda menjadi lebih deskriptif dengan standar basis data.
maple_shaft

Bagaimana ini akan mengambil waktu dari sesuatu? Anda harus melakukannya setidaknya dua kali untuk 'kasus luar'. Buat alat dan beberapa kelas yang dapat digunakan kembali dan tidak perlu khawatir lagi.
Steven Evers

Jawaban:


27

Ini adalah praktik yang cukup umum, meskipun saya tidak akan mengatakan dukungan adalah manfaat utama. Manfaat nyata untuk pendekatan ini adalah menjaga jejak audit. Ini juga tempat umum untuk memiliki kolom tambahan yang berisi nama pengguna pengguna yang membuat pembaruan terakhir.

Jika Anda berurusan dengan segala jenis data keuangan atau sensitif, saya yakin Anda pernah mendengar hal-hal seperti kepatuhan PCI & SOX . Memiliki jejak audit yang komprehensif sangat penting dalam memenuhi spesifikasi tersebut ..

Penafian: Namun ada, cara yang jauh lebih baik untuk mencapai jejak audit basis data> https://stackoverflow.com/questions/1051449/ideas-on-database-design-for-capturing-audit-trails


Maaf, lupa menyebutkan, kepatuhan PCI (dll.) Tidak berlaku, sudah ada jejak audit proses dalam log (SEMUA yang dicatat dengan cukup teliti).
Ed James

6
"(SEMUA yang dicatat dengan seksama)" apakah itu termasuk CreatedDate dan LastUpdatedDate? Jika demikian, mungkin Anda bisa mengarahkan kolega Anda ke prinsip KERING :)
MattDavey

2
Itu poin yang sangat bagus, mungkin saya harus mendorong untuk parser log yang lebih efisien yang dapat kita gunakan untuk dengan mudah meminta data yang diarsipkan (jelas data tersebut untuk keperluan jejak audit sehingga kami tidak menyimpan lebih dari satu minggu atau lebih yang layak tersedia untuk permintaan, sisanya disimpan).
Ed James

3
Saya tidak berpikir pendekatan ini akan menghasilkan jejak audit yang kaya ... Saya bahkan tidak akan menyebutnya jejak audit sama sekali.
Jordão

@ Jordão Saya katakan itu pendekatan yang umum, saya tidak mengatakan itu pendekatan yang bagus! Oleh karena itu penafian :)
MattDavey

17

Argumen sebelumnya tidak valid, karena menambahkan beberapa basis data yang dikelola bidang timestamp ke serangkaian tabel bukanlah pekerjaan yang sulit. Ini sebenarnya jenis tugas yang mematikan pikiran yang akan diberikan seseorang kepada junior atau magang, dan mereka dapat dengan mudah melakukannya dalam sprint dua minggu tunggal dengan waktu luang.

Mungkin atau mungkin bahkan tidak diperlukan untuk memetakan bidang ini di ORM Anda, hanya karena Anda tidak ingin pengguna aplikasi memodifikasi bidang ini dan karena mereka berguna untuk pemeliharaan dan debugging dan jarang digunakan dalam logika bisnis. Saya bekerja di toko-toko yang melakukan keduanya dan saya terus terang tidak memiliki banyak pendapat tentang hal ini.

Keuntungannya, bahkan jika berlebihan masih jauh lebih besar daripada biaya manusia dalam mengimplementasikan fungsionalitas tersebut di tingkat basis data, dan tentu saja mungkin kurang dari kekuatan otak kolektif dari proyek-proyek yang dipikirkan oleh para ahli teknis yang hebat yang membajak rapat dan memeriksanya dalam pertandingan debat dada epik. Ketika Anda menghitung dampak yang ditimbulkan oleh beberapa pertemuan 1 jam terhadap umur proyek, Anda mungkin tidak akan terkejut bahwa itu mahal. Bayangkan upah kolektif per jam dan manfaat semua orang yang digabungkan dan itu akan memberi Anda ide.


8
Buat skrip yang akan menambahkan kolom ini ke setiap tabel jika belum ada bersama dengan pemicu.
JeffO

3
+1 Anda dapat membuat kode skrip dengan mudah dalam beberapa hari. Hanya banyak pekerjaan jika dilakukan secara manual.
Jon Raynor 8/11

8

... semakin banyak pernyataan definitif seorang pria, semakin besar kemungkinan dia salah secara pasti ... - tyler durden

ini berlaku untuk selimut "standar", sementara di beberapa meja ini bisa menjadi kemenangan besar, di setiap meja itu kemungkinan besar akan menjadi suara tidak berguna dan lebih banyak kode untuk mempertahankan atau lupa untuk mempertahankan.

ada keseimbangan yang bisa didapat di sini, itulah yang harus Anda dorong kepada para pengambil keputusan.


8

Saya setuju dengan sepenuh hati. Hampir setiap tabel di setiap database harus memiliki setidaknya 2 bidang: tanggal pembuatan dan tanggal pembaruan . Ada banyak alasan mengapa Anda harus membuat tanggal pembuatan dan tanggal pembaruan. Untuk alasan yang jelas yang dinyatakan orang sebelumnya ... yaitu audit.

Saya telah merancang sistem dan basis data selama 25 tahun dan telah bekerja untuk ratusan klien. Tidak ada satu klien pun yang TIDAK membutuhkan ini.

Ada 2 cara dasar untuk melakukan ini:

1 - Praktek pertama adalah membiarkan database melakukan pekerjaan dan memasukkannya langsung ke dalam desain tabel. Yang merupakan minimum, saya akan merekomendasikan.

2 - Praktek lain, yang saya suka .... menggunakan alat replikasi untuk menangani ini. Ada sedikit overhead dan tidak ada biaya untuk tim DEV. Namun alatnya mahal. Satu keuntungan tambahan adalah proses hapus bisa diaudit lebih mudah dengan alat jenis ini. Tanpa alat replikasi Anda perlu membuat tabel audit dan memicu pemicu penghapusan - bukan praktik yang baik menurut saya.

Manfaat lain untuk memiliki bidang ini adalah data warehouse dan ODS yang SELALU dibangun untuk sistem OLTP. Anda tidak bisa secara efektif menarik data tambahan tanpa itu. Kalau tidak, Anda berisiko harus memuat ulang seluruh DB setiap hari.

Ada banyak alasan bisnis lain untuk memasukkan 2 tanggal ini, yang tidak akan saya bahas di sini. Kerjakan pekerjaan rumah Anda dan saya yakin 3-6-12-48 bulan ke depan Anda akan sangat senang Anda menempatkan 2 bidang sederhana ini.

Saya telah menerapkan dan biasanya merekomendasikan kedua solusi jika memungkinkan.


5

Kami memiliki tanggal yang dibuat dan dibuat oleh kolom di basis data kami dan mereka telah sangat membantu kami dalam melacak masalah data. Jika kita perlu kembali, ada baiknya kita menemukan catatan yang benar di tabel audit lengkap (karena kita tahu ke mana harus mencari di tabel yang sangat besar). Dia harus menambahkan diciptakan oleh dan dimodifikasi oleh kolom juga. Sangat membantu untuk mengetahui siapa yang memasukkan data terutama jika Anda tidak memiliki audit penuh.

Saya tidak dapat memikirkan aplikasi Enterprise yang tidak perlu diaudit dalam bentuk apa pun. Rupanya bos Anda berpikir itu hanya membutuhkan audit yang relatif ringan. Secara pribadi saya mendukung audit penuh pada setiap basis data yang berisi data yang menjadi sandaran perusahaan Anda (jauh lebih mudah untuk mengembalikan 2.000 catatan buruk dari tabel audit daripada mengembalikan cadangan) dan akan memerlukannya jika ada informasi keuangan sama sekali seperti saya. telah melihat hal semacam ini membantu menangkap orang yang melakukan penipuan. Semua audit harus pada level basis data.

Bagaimana data ini dapat membantu? Yah pertama-tama mempersempit saat mencari untuk menemukan data lama (dalam revisi) dan ini dapat membantu Anda melihat versi program Anda yang aktif pada saat data dimasukkan. Jadi, jika Anda tahu Anda memperbaiki masalah itu di versi 2.3 yang ditayangkan pada 6 Juli 2011 dan kemudian menemukan masalah yang sama dengan catatan yang dimasukkan pada 7 Agustus, maka mungkin perbaikan Anda tidak baik. Jika Anda perlu kembali ke data lama, ini akan memberi tahu Anda versi cadangan mana yang dapat Anda temukan di data lama jika Anda tidak memiliki audit penuh.

Pengembang tampaknya jarang berpikir bahwa data harus dipelihara dari waktu ke waktu dan bahwa data yang buruk perlu diperbaiki oleh seseorang. Memiliki hal-hal seperti itu dapat sangat berharga bagi kita yang harus melakukan hal-hal seperti itu. Bos Anda benar, meskipun saya pikir dia tidak cukup jauh dalam mengaudit. Hanya perlu satu masalah serius yang mudah diperbaiki untuk menjustifikasi jumlah waktu yang sangat kecil untuk menambahkan kolom dan pemicu ini.


Saya lebih suka melihat orang secara efektif Menguji perbaikan mereka daripada mencoba memverifikasi mereka dengan cek DB, tapi saya menghargai maksud Anda. Namun, saya tidak yakin bahwa poin yang Anda buat akan berlaku untuk tabel SETIAP di semua database kami, bahkan tabel referensi dll.
Ed James

Tes unit terpisah dari audit. Saya menyebutkan bahwa itu mungkin menangkap bug karena saya telah melihat itu terjadi bahkan ketika ada unit test karena ada kasus tepi yang belum diuji. Mungkin juga menunjukkan data dimasukkan sebelum perbaikan bug dan kemudian Anda mungkin perlu mencari data lain yang juga perlu diperbaiki. Atau hanya tahu bahwa itu adalah data yang dimasukkan melalui impor pada 6 Juni 2016 yang akan membantu Anda melihat apakah masalahnya adalah sesuatu yang dilakukan impor Anda atau ada yang salah dengan data dalam file impor. Itu jauh lebih mudah daripada melihat-lihat file impor harian selama bertahun-tahun.
HLGEM

4

Beban kerja bisa diperdebatkan karena ini dapat ditulis dan diterapkan ke setiap basis data yang pernah Anda buat. Tambahkan kolom ke semua tabel bersama dengan pemicu. Anda hanya harus ingat untuk menjalankannya dengan build Anda.

Sejauh yang diinginkan klien, Anda dapat meminta mereka membayar Anda untuk mengintegrasikannya di aplikasi Anda sesuai keinginan mereka. Banyak yang suka melihat informasi tambahan pada catatan seperti siapa yang membuat / mengubahnya terakhir dan kapan. Tidak perlu mengirim email kepada semua orang untuk mencari tahu atau dibohongi. Anda tidak ingin harus meminta log setiap kali seseorang melihat catatan.

Memasukkannya ke dalam basis data dan membawanya ke sana untuk berjaga-jaga tidak sulit dan memungkinkan Anda membebankan biaya untuk fitur tambahan yang memanfaatkan bidang atau hanya untuk memberi Anda umpan balik tentang seberapa banyak klien menggunakan sistem.


Klien belum menyatakan pendapat tentang subjek (sejauh yang saya ketahui), dan mungkin tidak tahu tentang standar baru kami, jadi saya sangat berharap mereka tidak tertarik membayar untuk integrasi apa pun;) Namun, hal "bolehkan Anda minta bayaran" adalah argumen yang cukup bagus, jika sedikit bergantung pada "kekuatan" untuk pendekatan pembangunan yang biasa saya lakukan.
Ed James

1

Ini akan menjadi hal yang cukup sepele untuk diterapkan (mungkin total 1 hingga 3 hari), jadi menurut saya ini berapa nilai yang akan ditambahkan ke aplikasi Anda selama masa pakainya.

Pertama, pernyataan tabel alter diperlukan untuk menambahkan kolom, tabel alter semua akan sama (kecuali untuk nama tabel), sehingga Anda bisa menulis skrip untuk kode menghasilkan pernyataan alter alter untuk semua tabel ini diperlukan . Harus memungkinkan NULL untuk memperhitungkan data yang ada dan memeriksa keberadaan kolom sehingga dapat dijalankan kembali.

Kedua, untuk kolom, menggunakan nilai-nilai default, seperti GetUTCDate () (SQL Server, Oracle mungkin berbeda) memecahkan penambahan kode apa pun pada sisipan, sehingga basis kode tidak harus berubah untuk setiap pernyataan sisipan karena nilai default akan menjadi bekas.

Pembaruan data (perubahan ke modifikasi terakhir) dapat diselesaikan dengan pemicu pembaruan. Sekali lagi, pemicu ini akan hampir sama di semua tabel, jadi kode pemicu ini (SQL) dapat juga dihasilkan kode untuk setiap tabel yang ada.

Mungkin akan ada banyak kode skrip sql (tergantung pada berapa banyak tabel), tetapi suatu pola yang dapat diulang, sehingga Anda dapat membuat kode dengan melihat skema DB yang ada.


Saya khawatir bahwa dengan pendekatan big-band seperti itu Anda akan memiliki masalah pemeliharaan jangka panjang dengan tabel baru, atau bahwa (bahkan lebih buruk) Anda harus membuat sproc yang memindai setiap tabel untuk kolom bernama tertentu kemudian menghasilkan skrip DDL untuk menambahkannya jika hilang, yang terdengar seperti mimpi buruk pemeliharaan!
Ed James

Jika ini adalah standar, semoga pengembang membuat tabel baru mengikuti standar. Kalau tidak, ya, mimpi buruk. Pendekatannya adalah untuk mempercepat skema yang ada, setelah tanggung jawab pada pengembang untuk mengikuti standar.
Jon Raynor

Saya pikir kata kunci dalam komentar itu adalah "semoga", saya tidak yakin saya percaya apa pun yang harus terjadi atas kemauan masing-masing pengembang baru!
Ed James

2
@ Id - Setuju, tidak ada kepercayaan, untuk itulah ulasan kode! :)
Jon Raynor
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.