Bir tablodan diğerine veri taşımanın üç farklı yolu

Bir raporlama transaction'ında sıkça karşılaşılan durum: veritabanından okuduğunuz ham veriyi işleyip, farklı (genelde daha az kolonlu ya da filtrelenmiş) bir tabloya aktarmanız gerekir. TROIA burada tek bir komut yerine, ihtiyaca göre üç farklı araç sunuyor — hangisini seçtiğiniz performansı ve davranışı doğrudan etkiliyor.

COPY TABLE: birebir kopya

COPY TABLE {kaynaktablo} INTO {hedeftablo} [WITHFLAGS];

Kaynak tablonun tüm yapısını ve verisini hedefe kopyalar. WITHFLAGS verilirse, satırların INSERTED/UPDATED/DELETED gibi durum bayrakları da taşınır — bu, bir tabloyu değiştirmeden önce "yedeğini" alıp sonra karşılaştırmak istediğinizde işe yarar.

MOVE-CORRESPONDING: sadece ortak kolonlar

MOVE-CORRESPONDING {kaynaktablo} TO {hedeftablo} [WITHFLAGS];

İki tablonun yapısı birebir aynı olmak zorunda değil; sadece isim ve tip olarak eşleşen kolonlar taşınır. Bu, kaynak tablonun çok daha fazla kolona sahip olduğu ama hedefte sadece belirli alanların gerektiği senaryolarda COPY TABLE'a göre daha temiz bir çözümdür.

MERGETABLE: koşullu, toplu birleştirme

MERGETABLE {kaynak} INTO {hedef} [WITHFLAGS] WHERE {kosul};

WHERE koşuluna uyan satırları hedefe ekler/birleştirir — üçü arasında filtreleme yeteneği olan tek komut budur.

Gerçek bir örnek: aktif siparişleri özet tabloya taşımak

/* Ham sipariş tablosundan sadece aktif olanları özet tabloya taşır. */
LOCAL:
    TABLE HAMSIPARIS(ID INTEGER, DURUM CHAR(20), TUTAR DECIMAL, NOT_ CHAR(500));
    TABLE OZETSIPARIS(ID INTEGER, DURUM CHAR(20), TUTAR DECIMAL);

SELECT ID, DURUM, TUTAR, NOT_ FROM SIPARISLER INTO HAMSIPARIS;

/* OZETSIPARIS'te NOT_ kolonu yok; sadece ortak kolonlar taşınır */
MERGETABLE HAMSIPARIS INTO OZETSIPARIS WHERE DURUM = 'AKTIF';

Hangisini ne zaman seçmeli

  • Tam bir yedek/klon gerekiyorsa: COPY TABLE.
  • Farklı yapıdaki iki tablo arasında sadece ortak alanları taşımak istiyorsanız: MOVE-CORRESPONDING.
  • Koşula bağlı, seçici bir aktarım gerekiyorsa: MERGETABLE.

Sık yapılan hatalar

  • MOVE-CORRESPONDING'de kolon adlarının birebir eşleşmesini beklememek — kolon isimleri farklıysa (örneğin kaynakta MUSTERI_ADI, hedefte MUSTERIADI) o kolon sessizce atlanır, hata vermez. Beklenen kolonun gerçekten taşınıp taşınmadığını taşımadan sonra bir kez kontrol etmek iyi bir alışkanlıktır.
  • WITHFLAGS kullanmadan taşınan veriyi "değişmiş" sanmak — bayraklar taşınmazsa hedef tablodaki satırlar varsayılan duruma döner; sonradan "hangi satırlar değişti" sorusunu cevaplamanız gereken bir senaryo varsa WITHFLAGS şart.
  • MERGETABLE'ın "merge" adını birebir SQL MERGE gibi düşünmek — burada asıl kontrol WHERE koşuludur, iki tablo arasında anahtar bazlı bir upsert garantisi otomatik gelmez; aynı anahtarla tekrar taşırsanız duplicate satır oluşabilir, kendi tekilleştirme mantığınızı eklemeniz gerekebilir.
  • Büyük tablolarda COPY TABLE'ı gereksiz yere kullanmak — sadece birkaç kolona ihtiyacınız varken tüm tabloyu kopyalamak bellek tüketimini artırır; MOVE-CORRESPONDING çoğu zaman daha hafif bir seçimdir.

Sıradaki adım

Satır ve kolon silme (CLEAR ROW, CLEAR ALL, REMOVECOLUMN) konusuna bir sonraki yazıda değineceğim — verinin tablolar arasında nasıl taşındığını gördükten sonra, artık ihtiyaç duyulmayan veriyi nasıl temizleyeceğimize bakacağız.