“Hedef PostgreSQL mi olsun, SQL Server mı?” Bu soru genellikle bir veri projesinin ilk toplantısında sorulur ve cevabı çoğu kurumda zaten verilmiştir: kurumsal standart neyse odur.
Yine de kararın bedeli standardın kendisinde değil, aktarım tanımını kurarken karşınıza çıkan küçük farklarda birikir. İki hedef aynı kapsamda destekleniyor; ama aynı davranmıyorlar.
İki hedefte değişmeyen proje tanımı
Doğrulanmış haricî ilişkisel hedefler PostgreSQL ve Microsoft SQL Server’dır. Proje tanımı her ikisinde aynıdır: kaynak nesne seçilir, alanlar eşlenir, hedef tablo oluşturulur veya mevcut yapıyla karşılaştırılır, yükleme yöntemi ve paket ayarları belirlenir. Aktarımı başlatan komut SAP tarafına gönderilir; hedefteki tablo işlemleri veritabanına özgü sorgu oluşturucularla yürütülür.
Yani bu bir mimari kararı değil, bir işletme kararıdır. Sorulması gereken soru “hangisi daha hızlı?” değil, “hangisinin yedekleme, izleme ve yetki süreci sizde oturmuş?”
Tip eşlemesi, anahtar tanımı ve yetki üçlüsü
- Tip eşlemesi. SAP tarafındaki miktar, tarih ve karakter alanlarının karşılığı iki veritabanında birebir aynı değildir. Ondalık hassasiyetini ve metin uzunluğunu eşleme ekranında görmek, üretimde kesme hatası aramaktan iyidir.
- Anahtar ve upsert. Güncelleme/ekleme yöntemi anahtar alan tanımına dayanır. Anahtarı eksik bırakılmış bir tanım iki hedefte de sorun çıkarır, ama hatanın görünme biçimi farklı olur.
- Tablo bakımı. Hedef tabloya alan ekleme ve kullanım dışı alanı kaldırma işlemleri proje üzerinden yapılabilir. Veritabanı ekibinin bu işlemler için ayrı bir onay süreci olup olmadığını baştan sormak gerekir.
- Yetkiler. Aktarım kullanıcısının tablo oluşturma yetkisi mi var, yalnız yazma yetkisi mi? Bu, hangi tablo bakım seçeneklerini kullanabileceğinizi belirler.
Bu dört satır çoğu projede hedef tartışmasını kapatır. Kapatmadığı durumda sebep teknik değildir: iki ekip aynı veritabanını farklı olgunlukta işletiyordur. Hedef tablo önizlemesi ve kayıt sayımı ise iki hedefte de aynı ekrandan yapılır; ilk doğrulamayı bu ikisiyle kapatabilirsiniz.
Fabric’i üçüncü ilişkisel hedef sanmak
Microsoft Fabric’i üçüncü bir ilişkisel hedef gibi listelemek yaygın bir hata. SAP kaynağından Fabric hedefine giden akış OneLake yolunu kullanır; Delta ve Parquet dosya yapısıyla çalışır, JDBC tablo işlemleriyle değil. BI tarafındaki Fabric Warehouse bağlantısı ise Microsoft SQL Server uyumlu JDBC yoluyla çalışan ayrı bir bağlantı türüdür.
İkisini aynı cümlede “Fabric desteği” diye toplamak proje planında yanlış varsayım üretir: şema yönetimi, satır sayımı ve okuma davranışı iki yolda farklıdır.
Kapsam tarafında bir not daha: doğrulanmış haricî ilişkisel hedefler bu ikisiyle sınırlı. Oracle, MySQL veya bir bulut veri ambarı hedefi için bu akışı şimdiden plana yazmayın; ihtiyacınız varsa ayrı konuşalım.
Karar için şunu öneriyoruz: hedef tartışmasını hız üzerinden değil işletim modeli üzerinden yapın. Hangi taraf sizde oturmuşsa onu söyleyin; aynı aktarım tanımını o hedefte kurup tip eşlemesini alan alan birlikte gözden geçirelim.