ARGEKA Sync
Veri tipi farkları
En sık görülen sorunlardan biri SQL Server'daki veri tipinin PostgreSQL tarafında birebir karşılığının seçilmemesidir. `nvarchar` alanları PostgreSQL tarafında `text` veya uygun uzunlukta `varchar` olarak karşılanabilir. `datetime` ve `datetime2` alanlarında saat hassasiyeti, zaman dilimi ve boş değer davranışı kontrol edilmelidir. Para ve miktar alanlarında `decimal` hassasiyeti hedefte aynı şekilde korunmalıdır.
| SQL Server | PostgreSQL seçeneği | Kontrol notu |
|---|---|---|
| nvarchar/varchar | text veya varchar | Uzunluk kesilmesi ve karakter seti test edilmeli. |
| datetime/datetime2 | timestamp veya timestamptz | Zaman dilimi iş kuralına göre seçilmeli. |
| decimal/numeric | numeric | Precision ve scale aynı tutulmalı. |
| bit | boolean | 0/1 dönüşümü ve null davranışı kontrol edilmeli. |
| identity | generated identity veya sequence | Kaynak anahtar mı, hedef anahtar mı kullanılacak belirlenmeli. |
Kaynak sorguda artımlı okuma
Büyük tabloları her çalışmada baştan okumak hem kaynak sistemi yorar hem de aktarım süresini uzatır. Artımlı okuma için güncelleme tarihi, hareket tarihi veya monoton artan teknik anahtar kullanılabilir. Ancak sadece `created_at` alanına güvenmek, sonradan değişen kayıtları kaçırabilir. Bu yüzden iş kuralı kayıt güncellemesini gerektiriyorsa `updated_at` benzeri alan da değerlendirilmelidir.
ARGEKA Sync gibi SQL odaklı bir araçta kaynak sorgunun görünür kalması avantajdır. Teknik ekip filtreyi, index kullanımını ve tarih aralığını doğrudan inceleyebilir.
PostgreSQL tarafında upsert
PostgreSQL'de upsert davranışı çoğunlukla benzersiz anahtar veya unique index üzerinden tasarlanır. Hedef tabloda doğru unique kısıt yoksa “varsa güncelle, yoksa ekle” davranışı güvenilir çalışmaz. ERP verisinde belge numarası tek başına benzersiz olmayabilir; firma, dönem, belge tipi ve satır numarasıyla birlikte anahtar oluşturmak gerekebilir.
- Hedef tabloda unique davranışı açıkça tanımlanmalı.
- Kaynak sorguda anahtar kolonlar boş gelmemeli.
- Güncellenecek kolonlar ve korunacak kolonlar ayrılmalı.
- Silinen veya iptal edilen kayıtların hedefte nasıl temsil edileceği belirlenmeli.
Performans ve parça parça aktarım
Aktarım hacmi büyüdükçe tek seferde çok fazla veri taşımak yerine tarih aralığı veya anahtar aralığıyla parça parça ilerlemek daha güvenli olabilir. Böylece hata olduğunda tüm işin baştan çalışması gerekmez. Hedef tarafta indexlerin doğru kurulması da önemlidir; fakat aktarım sırasında aşırı index yükü yazma performansını düşürebilir.
İlk canlı deneme için küçük bir dönem, örneğin son bir gün veya belirli bir depo seçilebilir. Sonuç doğruysa aralık büyütülür. Bu yaklaşım hem kaynak performansını korur hem de veri doğrulamasını kolaylaştırır.
Test planı
Test planı sadece “kaç satır geldi?” sorusuyla bitmemelidir. Normal kayıt, Türkçe karakter içeren metin, null alan, uzun açıklama, yüksek decimal değer, tarih alanı, iptal kayıt ve mükerrer anahtar örnekleri ayrıca denenmelidir. Hedef rapor bu kayıtlarla doğru sonuç veriyorsa aktarım daha güvenli hale gelir.