PostgreSQL'de Sipariş Değişiklikleri: Veri Modeliniz Yeterli mi? – webdedik gönderisi

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.

Reklam · TEST
AdSense Test ReklamıYazı arası (gönderi içi) · Yazı arası

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.

Reklam · TEST
AdSense Test ReklamıGönderi altı · Görüntülü
konu hakkında tepkinizi verebilirsiniz