ProgramlamaKıdemli SQL Geliştirici

SQL tablolarında değişiklikleri izleme veya denetim mekanizması nasıl uygulanır? Hangi yaklaşımlar vardır, artıları ve eksileri nelerdir ve bu tür bir işlevselliği tasarlarken nelere dikkat etmek gerekir?

Hintsage yapay zeka asistanı ile mülakatları geçin

Cevap

Denetim mekanizması (log veya değişiklik geçmişi), verilerdeki tüm değişiklikleri takip etmek ve şeffaflık sağlamak için uygulanır. Birkaç temel yaklaşım vardır:

  1. Denetim Tetikleyicileri (Audit Triggers): Eski ve/veya yeni satır durumunu ayrı bir denetim tablosuna kaydeden özel AFTER/BEFORE INSERT/UPDATE/DELETE tetikleyicileri. Avantajı — uygulama için şeffaflık; dezavantajı — DML işlemlerinin yavaşlaması.

  2. Geçmişi Ayrı Bir Tabloda İzole Etme (History Table): Kayıtların sürümlemesi uygulanır — değişiklik yapıldığında "eski" satır, zaman damgası ile tarih tablosuna kopyalanır. Ana tablo yalnızca güncel verileri içerir.

  3. Yerleşik Mekanizmalar (Change Data Capture, Temporal Tables): Örneğin, SQL Server'da SYSTEM_VERSIONED TEMPORAL TABLE etkinleştirilebilir ve veritabanı otomatik olarak değişiklik geçmişini saklar.

Örnek (MySQL, denetim için tetikleyici):

CREATE TABLE user_audit ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT, action VARCHAR(10), old_value TEXT, new_value TEXT, changed_at DATETIME ); DELIMITER // CREATE TRIGGER audit_user_update AFTER UPDATE ON users FOR EACH ROW BEGIN INSERT INTO user_audit (user_id, action, old_value, new_value, changed_at) VALUES (OLD.id, 'UPDATE', OLD.name, NEW.name, NOW()); END// DELIMITER ;

Kandırmaca Sorusu

Soru: Tam bir değişiklik geçmişi protokolü gerekiyorsa, her zaman sadece UPDATE için bir denetim tetikleyici yeterli midir?

Cevap: Hayır. Tam geçmişi elde etmek için tüm işlem türleri için tetikleyicileri birleştirmek gerekir: INSERT (yeni satırları günlüğe kaydetmek), UPDATE (değişiklikleri günlüğe kaydetmek) ve DELETE (silinen kayıtları günlüğe kaydetmek).

Örnek:

-- Her işlem için 3 ayrı tetikleyici oluşturulmalıdır, aksi takdirde geçmişte "delikler" olacaktır.

Konunun inceliklerini bilmemekten kaynaklanan gerçek hata örnekleri


Hikaye 1: Şirket sadece UPDATE tetikleyicisi kullanıyordu ve bir yıl boyunca silinen kayıtların kaydedilmediğini fark etmedi. Sonuç olarak, bir olayın araştırılması sırasında önemli bir kullanıcı hesabının ne zaman silindiğini öğrenemediler.


Hikaye 2: Proje, değişikliklerin eski ve yeni değerlerini bir metin alanında seri hale getirilmiş JSON biçiminde sakladı, bu da analizi büyük ölçüde zorlaştırdı — karmaşık ayrıştırıcılar ve raporlama için ayrı bir veritabanı yedeği gerekti.


Hikaye 3: Yüksek yüklü bir veritabanında geliştiriciler, log tablosunun boyutundaki artışı dikkate almadan tetikleyicilerle denetim uyguladılar. Zamanla, tarih tablosu ana tablodan 50 kat fazla oldu, bu da depolama alanının dolmasına ve tüm projede arızalara neden oldu.