Bir veritabanı tablosu ne zaman zaman damgaları kullanmalıdır?

İlk olarak, belki de bu sorunun veritabanı değişimine ait olduğunu düşündüm, ancak veritabanları yerine bir bütün olarak bir programlama çözümü ile daha ilgili olduğunu düşünüyorum. İnsanlar en iyisi bu düşünürseniz veritabanı değişimine geçecek.

Bir veritabanı tablosunun ne zaman oluşturulmuş ve güncellenmiş bir zaman damgası eklenmesi gerektiğini merak ediyordum?

İlk açık cevap, herhangi bir iş mantığının bir şeyin ne zaman güncellendiğini bilmesi gerektiğinde (işlem tamamlanma tarihi gibi) girmesi gerekir.

Peki ya ticari olmayan mantık vakaları? Örneğin, hata bulmaya yardımcı olmak için satırların değiştirildiği tarih saatini bilmenin gerçekten yararlı olacağı senaryoları düşünebilirim, örneğin, bazı iş mantığı başarısız oluyor ve ilgili veritabanı satırlarına bakarak, bir satırın daha önce güncellenmekte olduğunu tanımlamak mümkün hataya neden olan başka bir satır.

Bu kullanım durumunda, her tabloya bir güncelleme vermek ve zaman damgası oluşturmak mantıklı olacaktır (belki de uygulamanın herhangi bir kısmı tarafından güncellenmeyecek en önemsiz numaralandırma tabloları hariç).

Her tabloya zaman damgası vermek, bir veritabanını hızlı bir şekilde aşağı çekmek için harika bir yoldur (her ne kadar yanlış olabilir).

Peki bir veritabanı tablosu ne zaman oluşturulmalı ve zaman damgaları güncellenmelidir?

Daha iyi ve daha kapsamlı bir veritabanı yönetimi ve en akıllıca uygulama için bunu yapmaktır.

Birincisi, bir geliştirici olarak daha olasıdır, veritabanı işlemlerini ve / veya geliştirme faaliyetlerini takip etmek ve veritabanınızı içerdiğinde kodunuzdaki hataları ve hataları takip etmeyi kolaylaştırmak istersiniz .

Ayrıca, istatistik amaçlı olarak veritabanınızda yapılan etkinlikleri izlemeniz gerektiğinde .

Başka bir, genellikle şu an için veritabanı aktivitelerinizi takip etmek zorunda değilsiniz, ancak gelecekte olması muhtemeldir. Bugün zamanınıza ihtiyacı olacak, ancak gelecekte daha fazla satın alır .

Hem kaçak avcı (geliştirici) hem de gamekeeper (DBA) olan biri olarak, birçoğunun hala buradaki değeri görmediğine ve şişkin olduğunu düşünmesine şaşırdım.

Basit ifadeyle:

Kayıtlar eklenir (ancak asla güncellenmez) herhangi bir tablo için örneğin oturum açma vb. Ben bir DATE_CREATED sütun eklemeyi düşünün.

Kayıtların eklendiği ve güncellendiği herhangi bir tablo için bir DATE_CREATED ve bir DATE_UPDATED sütunu eklemeyi düşünürüm.

DATE_CREATED ve DATE_UPDATED değerlerinin, tasarımın bir parçası olarak varsayılan olarak her tabloya dahil olduğu birçok yerde çalıştım.

Veritabanı güncellemesinin birkaç gün boyunca çalıştığı milyonlarca / milyarlarca satır içeren daha büyük veritabanları için, hangi veri kabının güncelleştirmeye neden olduğunu izleyen bazı tablolar için bir kaynak sütunu ekledik, örneğin 3. taraf feed'i, kullanıcı güncellemesi, DBA değişikliği, veri temizleme vb.

Sorunun ifade şekli, bir şeyler listesi istiyorsunuz. Sorunuza doğrudan cevap vermeme, ne zaman alternatif bir çözüm kullanmanız gerektiğine yanıt verme riskiyle karşı karşıya kalacağım.

Hata bulmaya yardımcı olmak için satırların değiştiği tarih saatini bilmenin gerçekten yararlı olacağı senaryoları düşünebilirim

Belirli bir kayıt için tüm güncellemelerin bir günlüğüne sahip olmak daha yararlı olur mu? Sadece son güncellemeyi bilmek yeterli bilgi olmayabilir. Bu günlük ayrı bir tabloya konabilir. Aynı günlük dosyalarındaki birkaç tablodaki değişiklikleri izlemek daha uygun olur (tablo olması gerekmez). Bu, tüm tablo değişiklik_tarihleri ​​toplu toplama almak için büyük bir birleşim sorgusu önler. Bu, sisteminizde daha fazla olayın kaydını görmenize yardımcı olarak sorun gidermeye de fayda sağlayacaktır.

Ayrıca: Kullanıcıları da göz önünde bulundurmalısınız. Bunu bir iş durumu haline getirmeyebilirler, ancak deneyimsiz kullanıcılarınız veya asla bir kullanıcı hatası yapmadıkları ve her zaman bilgisayarda suçlamak istedikleri şirket kültürü olanlarınız varsa, her türlü günlük kaydı tablolardaki güncelleme tarihlerini dahil etmeye yardımcı olacaktır. Bu durumda, bir Update_UserID alanına da sahip olmak isteyebilirsiniz.

Bir veritabanı tablosu, aşağıdakilerden biri doğru olduğunda oluşturma ve değiştirme şablonlarını içermelidir:

1. Tablo , kullanıcı tarafından sağlanan bazı etkinliklerin birincil kaydını temsil eder . Kullanıcı X yapıyorsa ve hem a'nın hem de bir Table_Xila birden fazla Table_Yçocuğunuz varsa Table_X,Table_Y ekstra alanlar gerekmez böylece birincil rekor değil ve.
2. Sistem izleme için kalıcı, geçici veya yinelenen bir gereksiniminiz olduğunda . Table_YYalnızca güncellendiğinde güncellenip güncellenmediğini kontrol etmeniz gerekiyorsa Table_X, ekstra izleme alanları yardımcı olabilir.

Bunların hiçbirinin münhasır olmadığını unutmayın; devam edip varsayılan olarak her yere ekleyebilirsiniz ve yalnızca performans ayarı için gerektiğinde atlayabilirsiniz.

Kişisel görüş:

Bir modifiedsütundaki değeri göremiyorum .

created, istisnai bir durum olmadığı sürece her veritabanı tablosuna kesinlikle eklenmelidir yapmak için gerekçe . Oraya sahip olmanın çok değeri var.

Ancak, updatedbir atık gibi görünüyor. Neden sadece tüm domuz gitmek değil, biri bir belge kimliği ve diğeri belge sürümü belirten iki veritabanı tablolar yapmak. Çok basit bir durumda

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
);

Sonra son seçmek versionarasında documentistediğiniz. Bu şekilde, yalnızca son değişiklik tarihini değil, her değişiklik tarihini kaydetmekle kalmaz, aynı zamanda bu belgenin her sürümünü de saklarsınız . Buna karşı tek argüman gerçekten sabit disk alanıdır, ancak elbette hangi sabit disk alanını kullandığından rahatsız olduğunuzda, çoğu durumda verilerin sürümlendirilmesinden daha fazla rahatsız olursunuz.