Kapan tabel database menggunakan cap waktu?


18

Pertama catatan, saya pikir mungkin pertanyaan ini termasuk dalam pertukaran database, tapi saya pikir ini lebih luas terkait dengan solusi pemrograman secara keseluruhan daripada ke database. Akan pindah ke pertukaran basis data jika orang berpikir itu yang terbaik.

Saya bertanya-tanya kapan tabel database harus memiliki cap waktu yang dibuat dan diperbarui ditambahkan?

Jawaban pertama yang jelas adalah bahwa jika ada logika bisnis perlu tahu kapan sesuatu diperbarui (seperti tanggal penyelesaian transaksi dll) maka harus masuk.

Tetapi bagaimana dengan kasus-kasus logika bisnis non? Sebagai contoh, saya dapat memikirkan skenario di mana akan sangat berguna untuk mengetahui waktu tanggal dimana baris diubah untuk membantu menemukan kesalahan misalnya beberapa logika bisnis gagal dan melihat pada baris database terkait mungkin untuk mengidentifikasi bahwa satu baris sedang diperbarui sebelum baris lain yang menyebabkan kesalahan.

Dengan use case ini, masuk akal untuk memberi setiap tabel pembaruan dan membuat stempel waktu (kecuali mungkin tabel enum paling sepele yang tidak akan diperbarui oleh bagian mana pun dari aplikasi).

Memberi setiap tabel stempel waktu pasti merupakan cara yang bagus untuk dengan cepat menurunkan basis data (meskipun mungkin salah).

Jadi kapan seharusnya tabel database menggunakan buat dan perbarui cap waktu?


2
Saya pikir Anda sudah menjawab pertanyaan itu sendiri. Satu-satunya jawaban yang bisa diberikan adalah "Itu tergantung pada skenario".
Philipp

3
Dalam praktiknya saya memiliki cap waktu di hampir setiap meja (kebanyakan karena alasan yang Anda sebutkan). Sejauh yang bisa saya katakan ini tidak memiliki efek negatif pada kinerja, setidaknya untuk jenis database yang umum digunakan dalam pengembangan web dengan mungkin sekitar 30.000 artikel dan ratusan ribu pesanan (yang memerlukan stempel waktu pula). Mungkin ada kasus tepi, tetapi misalnya sistem ERP kami (Microsoft Navision) memiliki stempel waktu pada kebanyakan tabel juga.
thorsten müller

2
Anda mengatakan Memberi setiap tabel stempel waktu pasti merupakan cara yang bagus untuk dengan cepat menurunkan database , tetapi Anda tidak mengatakan mengapa. Di hampir setiap DBMS, cap waktu adalah nilai yang sangat kecil - biasanya 8 byte atau kurang. Kecuali Anda menambahkan indeks, itu dapat diabaikan.
Ross Patterson

Memperbarui cap waktu karena ada perubahan untuk saya. Itu berarti Anda hanya akan memiliki waktu perubahan terbaru ke catatan, yang Anda inginkan dalam bisnis adalah memiliki riwayat semua perubahan.
Pieter B

@PieterB Pasti ada nilai dalam menjaga sejarah untuk beberapa tabel tapi saya belum pernah menemukan kasus di mana Anda ingin melakukan ini untuk setiap tabel - YMMV.
Robbie Dee

Jawaban:


5

Untuk manajemen basis data yang lebih baik dan lebih komprehensif dan praktik paling bijak adalah melakukannya.

Pertama, lebih mungkin sebagai pengembang, Anda ingin melacak transaksi basis data dan / atau kegiatan untuk pengembangan dan kemudahan melacak bug dan kesalahan pada kode Anda setiap kali melibatkan basis data Anda.

Juga, setiap kali Anda perlu melacak aktivitas yang dilakukan pada basis data Anda untuk keperluan statistik .

Lain, sering terjadi bahwa mungkin untuk saat ini Anda tidak perlu melacak kegiatan basis data Anda, tetapi kemungkinan besar Anda akan melakukannya di masa depan. Ini akan membutuhkan waktu Anda hari ini, tetapi membeli Anda lebih banyak di masa depan .


15

Sebagai seseorang yang telah menjadi pemburu liar (pengembang) dan pengawas binatang peliharaan (DBA), saya terkejut banyak orang masih tidak melihat nilai dalam hal ini dan menganggapnya gembung.

Sederhananya:

Untuk setiap tabel di mana catatan ditambahkan (tetapi tidak pernah diperbarui) misalnya login dll. Saya akan pertimbangkan untuk menambahkan kolom DATE_CREATED.

Untuk tabel mana pun di mana catatan ditambahkan dan diperbarui, saya akan mempertimbangkan untuk menambah kolom DATE_CREATED dan DATE_UPDATED.

Saya telah bekerja di banyak tempat di mana DATE_CREATED dan DATE_UPDATED dimasukkan dalam setiap tabel secara default sebagai bagian dari desain.

Untuk basis data yang lebih besar dengan jutaan / miliaran baris di mana pembaruan basis data berlangsung selama beberapa hari, kami juga menambahkan kolom SUMBER untuk beberapa tabel yang melacak pot data mana yang menyebabkan pembaruan misalnya umpan pihak ke-3, pembaruan pengguna, modifikasi DBA, membersihkan data dll.


6

Cara pertanyaannya adalah kata, Anda meminta daftar hal-hal. Saya akan mengambil risiko tidak langsung menjawab pertanyaan Anda, tetapi menjawab kapan Anda harus menggunakan solusi alternatif.

Saya bisa memikirkan skenario di mana akan sangat berguna untuk mengetahui waktu tanggal baris diubah untuk membantu menemukan kesalahan

Apakah akan lebih bermanfaat untuk memiliki log semua pembaruan untuk catatan yang diberikan? Hanya mengetahui pembaruan terakhir, mungkin tidak cukup informasi. Log ini dapat dimasukkan ke dalam tabel terpisah. Akan lebih mudah untuk melacak perubahan dari beberapa tabel dalam file log yang sama (tidak harus berupa tabel). Ini mencegah beberapa permintaan gabungan besar-besaran dari semua tabel change_date untuk mendapatkan agregat. Ini juga akan bermanfaat untuk pemecahan masalah dengan membantu Anda melihat rekaman lebih banyak peristiwa di sistem Anda.

Selain itu: Anda harus mempertimbangkan pengguna juga. Mereka mungkin tidak menjadikannya sebagai kasus bisnis, tetapi ketika Anda memiliki pengguna yang tidak berpengalaman atau yang berada dalam budaya perusahaan di mana mereka tidak pernah membuat kesalahan pengguna dan ingin selalu menyalahkannya di komputer, segala jenis pencatatan akan membantu termasuk memperbarui tanggal pada tabel. Dalam hal ini, Anda mungkin ingin memiliki bidang Update_UserID juga.


+1 Ini juga merupakan teknik umum yang dapat digunakan melalui pemicu tabel untuk melempar catatan ke dalam tabel riwayat yang kemudian dapat dihapus. Beberapa RDBMS (misalnya fitur Flashback Oracle) juga mendukung penggunaan kueri titik waktu di mana keadaan data di beberapa titik di masa lalu dapat diperiksa.
Robbie Dee

Apakah solusi sederhana untuk menyimpan kueri yang diperbarui dan tabel ke log?
Gaz_Edge

Itu adalah cara lain walaupun mungkin menjadi sulit untuk tabel dengan volume / frekuensi pembaruan yang tinggi. Menjadikannya meja eksternal bisa mengatasi beberapa masalah ...
Robbie Dee

1

Tabel database harus menyertakan template kreasi dan modifikasi ketika salah satu dari berikut ini benar:

  1. Tabel tersebut merupakan catatan utama dari beberapa aktivitas yang disediakan pengguna. Jika pengguna melakukan X, dan Anda memiliki a Table_Xdan Table_Yyang merupakan anak satu-ke-banyak Table_X, Table_Ybukan catatan primer dan karenanya tidak memerlukan bidang tambahan.
  2. Ketika Anda memiliki kebutuhan permanen, sementara, atau berulang untuk pelacakan sistem . Jika Anda perlu memeriksa bahwa Table_Yhanya diperbarui ketika Table_Xdiperbarui, bidang pelacakan tambahan dapat membantu.

Perhatikan bahwa keduanya tidak eksklusif; Anda dapat melanjutkan dan menambahkannya di mana saja secara default, dan mengabaikannya hanya saat diperlukan untuk penyetelan kinerja.


0

Opini pribadi:

Saya tidak melihat nilai di modifiedkolom.

created, tentu saja, harus ditambahkan ke setiap tabel database kecuali ada justifikasi luar biasa untuk tidak melakukannya. Ada begitu banyak nilai untuk memilikinya di sana.

Namun, updatedsepertinya sia-sia. Mengapa tidak pergi saja ke seluruh babi, buat dua tabel basis data, satu yang menentukan ID dokumen dan satu lagi versi dokumen. Dalam kasus yang sangat sederhana

create table document (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create table version (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    document_id INT NOT NULL REFERENCES document(id),
    content TEXT NOT NULL,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

Kemudian pilih yang terbaru versionyang documentAnda inginkan. Dengan cara ini, Anda tidak hanya menyimpan setiap tanggal modifikasi - bukan hanya yang terakhir - tetapi Anda juga menyimpan setiap versi dokumen itu. Satu-satunya argumen yang menentangnya adalah ruang hard drive, tetapi tentu saja ketika Anda sampai pada titik ketika Anda terganggu tentang ruang hard drive yang digunakannya - dalam kebanyakan kasus Anda bahkan akan lebih terganggu dengan mengversi data.

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.