PostgreSQL'de Sipariş Değişiklikleri: Veri Modeliniz Yeterli mi?
Tasarladığın model statik durumu iyi temsil ediyor, ama gerçek dünya dinamik, müşteriler fikir değiştirir, siparişleri iptal eder, miktarları azaltır. 3 kaynağı 6 aya sipariş eden bir müşteri 3. ayda 2'ye düşürmek isterse ne olur? Mevcut tablolarında bu değişikliği kaydetmen ve eski durumu koruman gerekir.
Sorunun çekirdeği: Commitments ve Reservations statik bağlantılar. Bir commitment oluşturulduktan sonra değişmez, sadece silinir, ama silersen tarihsel veri kaybedersin. Bunun yerine bir versiyonlama veya event-tabanlı yaklaşım düşün.
Pratik çözüm: Her order değişikliğini yeni bir kayıt olarak sakla, eski olanı soft-delete (is_active veya valid_until gibi bir alan) ile işaretle. Böylece commitments ve reservations otomatik olarak doğru versiyona bağlanır. Örneğin Orders tablosuna order_version ve effective_date ekle. Müşteri 3. ayda 2 kaynağa düşürürse, yeni bir order_version satırı oluştur, eski olanı is_active=false yap.
Alternatif: Event sourcing. Her değişikliği (OrderCreated, OrderModified, OrderCancelled) ayrı bir events tablosunda kaydet. Commitments ve Reservations bu olaylardan türetilir. Daha esnek, ama karmaşık.
En önemli: Reservations'a bir end_date veya cancellation_reason alanı ekle. Bir commitment iptal edildiğinde, onunla bağlı reservation'lar da sonlandırılmalı. Foreign key constraints ve triggers ile tutarlılığı sağla.
Version kontrolü ve soft-delete kombinasyonu çoğu durumda yeterli. Tarihsel doğruluk korunur, sorgular hala hızlı kalır.
0 yorum