Değişikliklerin kayıtlarını tutmak için bir veritabanı ve tablo tasarlamanın en iyi yolu?

Önceki değişiklikleri takip etmek için bir projede bir geçmiş özelliği ayarlamam gerekiyor.

Diyelim ki şu anda iki masam var:

NOTES TABLE (id, userid, submissionid, message)

SUBMISSIONS TABLE (id, name, userid, filepath)

Örnek: Notlarda bir satır var ve kullanıcı mesajı değiştirmek istiyor. Değişimden önce ve değişimden sonra durumunu takip etmek istiyorum.

Bu tabloların her birinde, bir öğenin "eski" olup olmadığını söyleyen bir sütun oluşturmak için en iyi yaklaşım nedir? Etkinse 0 VEYA silinmiş / görünmezse 1.

Ayrıca , önceki durumun, yeni durumun, bu kimliğin ilişkili olduğu AUDIT TRAILtabloyu içeren bir history ( ) tablosu oluşturmak istiyorum.idid

Lütfen görüntüleyin

http://www.codeproject.com/Articles/105768/Audit-Trail-Tracing-Data-Changes-in-Database

Veritabanı tasarımınızda bir Denetim İzi oluşturma yaklaşımları hakkında çok iyi bir okuma. Denetim izleri, bir veritabanının uygulanması için gereklidir. Her zaman sistem içindeki veritabanı kullanıcılarının eylemlerini görebilmelisiniz.

PTA ilgisi olan tüm tablolara bazı standart PTA (zaman içinde) sütunları ekleyerek PTA (Zamanında Nokta) sistemimizde hangi satırların değiştirildiğini takip edebiliriz.

Aşağıdakileri öneririm:

DateCreated – the actual date on which the given row was inserted.
DateEffective – the date on which the given row became effective.
DateEnd – the date on which the given row ceased to be effective.
DateReplaced – the date on which the given row was replaced by another row.
OperatorCode – the unique identifier of the person (or system) that created the row.

Verilerinizde sürüm oluşturma yetenekleri tasarlarken, birkaç minimum (sanırım) gereksinim vardır:

• Verilerin her sürümü bağımsız olmalı ve diğer sürümlerden bağımsız olmalıdır. Bu, geçerli sürümün hangisinin "geçmiş" olduğunu gösteren hiçbir işaret veya başka bir gösterge olmadığı anlamına gelir. Ayrıca varlığı güncellemek, yalnızca yeni bir sürüm eklemek anlamına gelir - önceki sürümlerin güncellenmesine gerek yoktur.
• Satır Genişleme Bağımlılığı dediğim şeyden kaçının. Burada, bir satırdaki bir alanın (End_Date) farklı bir satırın başka bir alanıyla (Start_Date) senkronize kalması gerekir. Bu, verilerle çalışmayı zorlaştırır ve mükemmel bir anomali kaynağıdır.
• Geçerli sürüm ve geçmiş tüm sürümler aynı tabloda olmalıdır. Bu, belirli bir tarih itibarıyla "geçmiş verileri" görüntülemek ve geçerli verileri görüntülemek için aynı sorguyu kullanmayı mümkün kılar.
• Sürümlendirilmiş verilerin yabancı anahtarları normal (sürüm bilgisi olmayan) verilerle aynı şekilde çalışmalıdır.
• Tasarım o kadar basit veya evrensel olarak anlaşılmalıdır ki, yeni geliştiriciler için öğrenme eğrisi en aza indirilmiştir.

İşte teknoloji fuarlarında birkaç kez yaptığım bir sunumun slaytları. Yukarıdakilerin hepsinin nasıl yapılabileceğini kapsar. Ve işte daha ayrıntılı bir belge. Belge için özür dilemeliyim - bu devam eden bir çalışmadır ve tüm bölümler tamamlanmamıştır. Ancak, basit sürüm oluşturmadan tam zamanlı geçici erişime kadar her şeyi uygulamak için gereken tüm bilgileri vermelidir.