Sql & Veritabanı İle Uygulamalar İçin Veri Kayıt İşlem Logu Nasıl Yapılır?

Gereksinimler ve Ön Hazırlık

Veri kayıt işlem logu oluşturmaya başlamadan önce, projenizin altyapısında aşağıdaki bileşenlerin hazır olduğundan emin olmalısınız. Bu rehber 2026 standartlarını temel almaktadır.

• Veritabanı Yönetim Sistemi: İlişkisel bir veritabanı (RDBMS) kullanıyor olmalısınız.
• Kullanıcı Kimlik Doğrulama: İşlemi yapan kişinin kimliğini (User ID) log tablosuna yazabilmek için uygulamanızda aktif bir oturum yönetimi bulunmalıdır.
• SQL Bilgisi: Trigger (tetikleyici) ve Procedure (saklı yordam) kavramlarına hakimiyet, loglama sürecini otomatize etmek için gereklidir.
• Yetkilendirme: Log tablolarına yazma yetkisi olan bir veritabanı kullanıcısı (service account) tanımlanmış olmalıdır.

Adım 1: Log Tablosunun Tasarımı

Loglama sisteminin temeli, tutulan verinin yapısıdır. Hangi tablonun, hangi satırının değiştiğini ve değişikliğin ne olduğunu kaydedecek merkezi bir tabloya ihtiyacınız vardır. Bu tablo, tüm uygulama için "tek kaynak" görevi görür.

CREATE TABLE audit_logs (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    table_name VARCHAR(100) NOT NULL,
    record_id BIGINT NOT NULL,
    action_type ENUM('INSERT', 'UPDATE', 'DELETE') NOT NULL,
    old_value JSON,
    new_value JSON,
    changed_by INT NOT NULL,
    changed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Yukarıdaki SQL kodu, JSON veri tipini kullanarak eski ve yeni değerleri esnek bir yapıda saklamamıza olanak tanır. Bu sayede, farklı tablolardan gelen verileri tek bir tabloda normalize bir şekilde tutabilirsiniz.

Adım 2: Veritabanı Trigger (Tetikleyici) Kullanımı

Uygulama katmanında loglama yapmak yerine veritabanı seviyesinde trigger kullanmak, veri tutarlılığını garanti altına alır. Triggerlar, bir tablo üzerinde belirtilen işlem (INSERT, UPDATE, DELETE) gerçekleştiği anda otomatik olarak tetiklenir.

DELIMITER //
CREATE TRIGGER after_user_update
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
    INSERT INTO audit_logs (table_name, record_id, action_type, old_value, new_value, changed_by)
    VALUES ('users', OLD.id, 'UPDATE', JSON_OBJECT('email', OLD.email), JSON_OBJECT('email', NEW.email), @current_user_id);
END;
//
DELIMITER ;

Bu örnekte, users tablosunda bir güncelleme yapıldığında, eski ve yeni e-posta adresi otomatik olarak log tablosuna kaydedilir. @current_user_id değişkeni, uygulama katmanından veritabanı oturumuna aktarılan kullanıcı bilgisini temsil eder.

Adım 3: Uygulama Katmanında Loglama (Middleware Yaklaşımı)

Bazı durumlarda veritabanı triggerları yerine, uygulama katmanındaki "Middleware" veya "Repository" desenini kullanmak daha avantajlı olabilir. Özellikle karmaşık iş mantığı içeren işlemlerde, verinin sadece veritabanındaki hali değil, iş akışındaki durumu da önemlidir.

// Örnek bir loglama fonksiyonu (Node.js/TypeScript yapısı)
async function logTransaction(tableName, recordId, action, oldData, newData, userId) {
    const query = 'INSERT INTO audit_logs (table_name, record_id, action_type, old_value, new_value, changed_by) VALUES (?, ?, ?, ?, ?, ?)';
    await db.execute(query, [tableName, recordId, action, JSON.stringify(oldData), JSON.stringify(newData), userId]);
}

Bu yaklaşım, veritabanı yükünü hafifletir ve loglama işlemini uygulama mantığına daha sıkı bağlar. Ancak, doğrudan veritabanı üzerinden yapılan manuel müdahalelerin loglanamayacağını unutmamalısınız.

Karşılaştırma: Trigger vs Uygulama Katmanı

Adım 4: Güvenlik ve Performans Optimizasyonu

Loglama sistemleri zamanla devasa boyutlara ulaşabilir. Bu durum veritabanı performansını doğrudan etkiler. SQL injection riskine karşı, loglama fonksiyonlarınızda mutlaka parametreli sorgular kullanın. Ayrıca, log tablolarını düzenli olarak arşivlemek veya "partitioning" (bölümleme) yöntemini kullanmak sistemin hızını korur.

Kritik Uyarı: Üretim ortamında log tablolarına doğrudan `DELETE` yetkisi vermeyin. Log verileri, bir denetim mekanizması olduğu için değiştirilemez (immutable) olmalıdır. Veri güvenliği için bu tablolara sadece `SELECT` ve `INSERT` izni tanımlayın.

Adım 5: Log Verilerini Görüntüleme ve Sorgulama

Logladığınız verileri anlamlı kılmak için gelişmiş sorgulama teknikleri kullanmalısınız. Örneğin, belirli bir kullanıcının son 30 günde yaptığı tüm değişiklikleri şu şekilde listeleyebilirsiniz:

SELECT * FROM audit_logs 
WHERE changed_by = 123 
AND changed_at >= DATE_SUB(NOW(), INTERVAL 30 DAY)
ORDER BY changed_at DESC;

Bu sorgu, sistem yöneticisinin şüpheli işlemleri tespit etmesine veya bir kullanıcının yaptığı hatalı veri girişlerini geri almasına (rollback) yardımcı olur.

Sıkça Sorulan Sorular

Log tablosu çok büyürse ne yapmalıyım?

Log tablolarını aylık olarak farklı tablolara bölebilir (partitioning) veya eski logları yedekleyerek veritabanından silebilirsiniz. "Data Archiving" stratejisi bu noktada hayat kurtarıcıdır.

JSON veri tipi kullanmak zorunda mıyım?

Zorunlu değilsiniz ancak modern veritabanları JSON desteğiyle çok daha esnek bir yapı sunar. İlişkisel bir yapıda tutmak isterseniz, her alan için ayrı bir sütun oluşturmanız gerekir ki bu da tablonun çok fazla genişlemesine neden olur.

Trigger kullanmak veritabanını yavaşlatır mı?

Evet, her `INSERT` veya `UPDATE` işleminde ekstra bir işlem yapıldığı için performans kaybı yaşanabilir. Bu yüzden sadece kritik tablolar için loglama yapmanız önerilir.

Loglar silinebilir mi?

Teknik olarak silinebilir ancak denetim (audit) gereksinimleri gereği log kayıtlarının silinmemesi veya değiştirilmemesi gerekir. Log tablosu üzerinde `DELETE` yetkisini kısıtlamak en güvenli yoldur.

Hangi verileri loglamalıyım?

Sadece hassas olmayan verileri loglamaya özen gösterin. Şifreler, kredi kartı bilgileri veya kişisel veriler (KVKK kapsamında) asla log tablolarına açık metin olarak yazılmamalıdır.

Yasal Sorumluluk Reddi: Bu rehberdeki kod örnekleri eğitim amaçlıdır. Veritabanı güvenliği ve veri gizliliği (KVKK/GDPR) konusunda uygulamanızın özel gereksinimlerine göre gerekli şifreleme ve anonimleştirme yöntemlerini uyguladığınızdan emin olun. Veri güvenliği sorumluluğu tamamen geliştiriciye aittir.

Loglama Stratejilerinde İleri Düzey Teknikler: Partitioning ve Arşivleme

Log tablolarınızın boyutu milyonlarca satıra ulaştığında, standart sorgular ciddi performans kayıplarına yol açar. Bu noktada, veritabanı seviyesinde Table Partitioning (Tablo Bölümleme) stratejisi devreye girer. Log verilerini aylık veya yıllık parçalara bölmek, veritabanı motorunun sadece ilgili zaman aralığını taramasını sağlayarak sorgu hızını dramatik şekilde artırır.

Aşağıdaki SQL örneği, PostgreSQL üzerinde log tablosunun zamana dayalı olarak nasıl bölümlenebileceğini göstermektedir:

CREATE TABLE system_logs (
    id SERIAL,
    event_type VARCHAR(50),
    log_data JSONB,
    created_at TIMESTAMP NOT NULL
) PARTITION BY RANGE (created_at);

CREATE TABLE system_logs_2023_q4 PARTITION OF system_logs
    FOR VALUES FROM ('2023-10-01') TO ('2024-01-01');

Bu yöntem sayesinde, eski logları silmek yerine ilgili partition tablosunu "detach" ederek veritabanı performansını koruyabilir ve eski verileri daha düşük maliyetli soğuk depolama alanlarına (Cold Storage) taşıyabilirsiniz.

Log Verilerinde Hata Ayıklama ve Anomali Tespiti

Sadece log tutmak yeterli değildir; bu logların içindeki hataları otomatik olarak tespit eden bir mekanizma kurmalısınız. Özellikle "kullanıcı hatası" ile "sistem hatası" arasındaki farkı ayırt edebilmek için log verilerinize bir Severity Level (Önem Derecesi) alanı eklemeniz kritik öneme sahiptir.

İşte log verilerinizde anomali tespiti yapmanıza yardımcı olacak örnek bir SQL sorgusu:

SELECT 
    DATE_TRUNC('hour', created_at) AS log_hour,
    COUNT(*) AS error_count
FROM system_logs
WHERE event_type = 'ERROR'
GROUP BY log_hour
HAVING COUNT(*) > 100
ORDER BY log_hour DESC;

Bu sorgu, son saatlerdeki hata yoğunluğunu takip ederek sisteminizde bir "hata patlaması" olup olmadığını anlamanızı sağlar. Eğer bir saat içinde 100'den fazla hata oluşmuşsa, bu durum sistemin o an bir saldırı altında veya kritik bir arıza yaşadığının göstergesi olabilir.

Loglama Süreçlerinde Dikkat Edilmesi Gereken İleri İpuçları

• Asenkron Loglama: Uygulama katmanında loglama yaparken, veritabanına yazma işlemini ana iş parçacığını (main thread) bloke etmeyecek şekilde, bir mesaj kuyruğu (RabbitMQ, Redis vb.) üzerinden gerçekleştirin.
• Contextual Logging: Sadece "ne olduğu" değil, "kimin yaptığı" (User ID) ve "hangi işlemden geldiği" (Request ID) bilgilerini mutlaka loglayın. Bu, mikroservis mimarilerinde izlenebilirliği (Distributed Tracing) sağlar.
• Maskeleme: Log tablosuna asla kredi kartı numarası, parola veya kişisel kimlik bilgisi (KVKK kapsamındaki veriler) açık metin olarak yazılmamalıdır. Veritabanına göndermeden önce bu alanları mutlaka maskeleyin veya hash'leyin.

Sonuç

Sql & veritabanı ile uygulamalar için veri kayıt işlem logu oluşturmak, sisteminizin izlenebilirliğini artırır ve olası hataların kaynağını bulmanızı kolaylaştırır. Trigger tabanlı yöntemler veri bütünlüğü için en güvenli yolu sunarken, uygulama katmanındaki çözümler esneklik sağlar. Bir sonraki adım olarak, log verilerini görselleştiren bir "Admin Dashboard" paneli oluşturarak bu kayıtları anlamlı raporlara dönüştürebilirsiniz. Başarılar dilerim.