Cevap.

Verit tablolarda toplu veri güncellemeleri, SQL'deki endüstriyel programlamada klasik bir problemdir. İş uygulamalarının gelişmesiyle, büyük veri hacimlerinin aynı anda güncellenmesine ihtiyaç doğdu ve bu verilerin tutarlılığının sağlanması gereklidir. Tarihsel olarak döngüsel senaryolarla bu sorunun üstesinden gelindi, bu da düşük performans ve uzun süreli kilitlenmelere yol açtı. Sonradan gelişmiş DML operatörleri (örneğin, MERGE), transaction yapıları ve staging tabloları ile yaklaşımlar ortaya çıktı.

Problem, verilerin güncellenmesinin ilişkili birçok tabloyu etkilemesinde yatmaktadır (örneğin, siparişler ve sipariş detayları), bu da "yetim" bağlantıların (orphan rows) ortaya çıkmasına, kilitlenmeler nedeniyle performans kaybına ve veritabanı üzerinde öngörülemeyen bir yük oluşmasına yol açabilir.

Çözüm, atomik işlemlerin kullanılması, JOIN koşulları ile UPDATE/DELETE/MERGE işlemleri ve veri batch işleme üzerine kuruludur. İyi bir uygulama, biriken değişikliklerin geçici staging tablolara bırakılması ve daha sonra bunların bir transaction içinden batch olarak uygulanmasıdır. SQL Server için MERGE ile bir örnek:

BEGIN TRANSACTION;

-- MERGE kullanarak ana ve ilişkili tablonun toplu güncelleme örneği
MERGE INTO orders AS tgt
USING temp_order_updates AS src
  ON tgt.id = src.id
WHEN MATCHED THEN
  UPDATE SET tgt.status = src.status, tgt.updated_at = src.updated_at;

MERGE INTO order_details AS tgt
USING temp_detail_updates AS src
  ON tgt.order_id = src.order_id AND tgt.sku = src.sku
WHEN MATCHED THEN
  UPDATE SET tgt.price = src.price, tgt.qty = src.qty;

COMMIT;

Anahtar özellikler:

İşlemleri tek bir transaction içinde izole etmek: geçici uyumsuzluk yok.
Değiştirilecek verilerin hazırlanması için staging tabloların kullanılması.
Kilitlenmeleri azaltmak ve yükü optimize etmek için batch işlemlerin uygulanması.

Çeldirici Sorular.

Ana tabloyu güncelleyip ardından ilişkili tabloları ayrı ayrı güncelleyebilir miyiz, eğer hız gereksinimleri yüksekse?

Transaction dışında ayrı ayrı yapılan UPDATE'ler, herhangi bir aşamadaki hata durumunda verilerin şiddetli uyumsuzluğuna yol açar — örneğin, siparişler güncellenir, ancak detaylar güncellenmezse, mantık bozulur. Modern veritabanlarında, transaction kullanımı batch işlemle ilgili neredeyse hiç ek maliyet oluşturmaz.

Bir büyük UPDATE ile alt sorgu yaparsak performans düşer mi? Bu kilitlenmelere yol açabilir mi?

Evet, büyük tablolarda monolitik UPDATE'ler kilitlenme çeşitliliğine, tablo kilitleri ve diğer kullanıcıların beklemelerine yol açmaktadır. İşlemi, WHERE ... AND rownum/id/limit kullanarak batch'lere ayırmak daha iyidir.

Batch örneği:

UPDATE orders
SET status = 'closed'
WHERE status = 'pending' AND id BETWEEN 100000 AND 199999;

MERGE, atomiklik ve ilişkili tablolardaki işlemlerin doğru sırasını garanti eder mi?

Hayır, MERGE bir tablo çerçevesinde çalışır. İlişkili tablolarda güncelleme yapmak için ayrı bir MERGE veya UPDATE gereklidir ve her iki işlemin de aynı transaction içinde yer alması zorunludur.

Tipik Hatalar ve Anti-Patternlar

Toplu değişikliklerde transaction eksikliği, bu da veri uyumsuzluğuna yol açar
Büyük tekil UPDATE/DELETE işlemleri için büyük seçim kümeleri ile LIMIT/BATCH kullanmadan: kilitlenmeler ve beklemeler
İşlem sırasının yanlış olması (örneğin, öncelikle detayları güncellemek, sonra ana tabloyu)

Gerçek Hayat Örneği

Negatif Durum

Şirket, ayrı sorgularla dışarıdan transaction olmadan bir milyon siparişin durumunu ("Tamamlandı") güncelliyordu: önce ana tabloda, sonra order_details detaylarında. Yük altında sunucu "çöktü" — bir hata durumunda detaylar "açık" durumda kalıyordu. Avantajlar:

Kolay uygulanabilir
Minimum kod

Dezavantajlar:

Veri uyumsuzluğu ve sonraki hata ayıklama zorluğu
Geri alma zorlukları

Pozitif Durum

Staging tabloları ve transaction içinde grup işleme entegre edildi. Öncelikle tüm değişiklikler hesaplanıp geçici tablolara yerleştirildi, ardından batch olarak her iki ana tablo güncellendi. Hata durumunda — tam geri alma. Avantajlar:

Veri tutarlılığı ve bütünlüğü garantisi
Kontrol ve geri alma kolaylığı