Veritabanı Federasyonu: Data API Builder Zincirleme ile Farklı Sistemleri Birleştirmek -

Q: “Linked Server” Bitti mi? Modern Çağın Federasyonunu Keşfet Şöyle ki, Şöyle bir dürüstçe sorayım: Eski “linked server” hikayesini kim unuttu? Zamanında, birleştir, bağla, veri çek – tamam! Hele İstanbul’daki o telekom projesinde şehirlerarası SQL’leri birbirine linked server ile eklediğimde... Ekibin yarısı alkışlamıştı. Kolaydı çünkü; sandığımızdan bile pratik geliyordu. Ama gün geldi devran değişti. Artık veri eskisi gibi sadece tek bir SQL sunucusunda durmuyor; Postgres var orada, Cosmos DB dolaşıyor bulutlarda… Bir de üstüne herkes “bana özel sandbox!” diye tutturunca, eski yöntemler elde kalıyor resmen. Peki şimdi ne yapacağız? Linked server’a izin yoksa (ya da kullanmak mümkün değilse) farklı veritabanlarından gelen datayı tek yerden kullanıcıya nasıl göstereceğiz? Uygulama geliştiricilerin şemaya dokunması da yasak... Cross-database özelliğini açmak mı? Hayal bile etme! Zincirin Gücü: Data API Builder ile Pratik Kompozisyon Birkaç ay önce Logosoft tarafında denk geldim bu mevzuya – büyük bankanın bulut göçü operasyonunda öyle bir tablo vardı ki anlatamam! Milyonlarca ürün kaydı SQL’de tutuluyor ama depo stoğu başka vendor’ın yönettiği Postgres üzerinde ve öneri motorunun çıktısı ise Cosmos DB’ye düşüyor… Lafı dolandırmaya gerek yok: Her şeyden canlı, taze bilgi çekip, tek REST API’dan sunmak şart oldu. Data API Builder (DAB) burada ciddi fark yaratıyor. Hatta geçen yıl detaylarına şurada değinmiştim. Ama zincirleme kombinasyon kısmı apayrı mesele gerçekten! 💡 Bilgi: DAB sayesinde artık ister klasik SQL ister NoSQL ister modern başka kaynak olsun, aynı anda sorgu atabiliyorsunuz — kod satırı yazmadan! Neden DAB Chaining?

Sınırlı erişim: Şema değiştirmene ya izin yok ya da ekip engelliyor mu? Fark etmez, çözülüyor. Karma platformlar: Veri MS SQL’den çıkıp Postgres’e sapabilir — sıkıntı yaşanmıyor. Kullanıcı deneyimi: Tek istekle full yanıt alacaksın; hız fena değil!

Q: Senkron Modelde Karşılaşılan Tuzaklar Nelerdir?

Kritik nokta şu:süreklilik/freshness vs gecikme/latency dengesi darmadağın olabilir. Ağ koparsa veya ilgili servis cevap vermezseKullanıcının ekranda saat başına dönmesine neden olursunuz ya da eksik datayla ekran dizmek zorunda kalırsınız. Maliyet detayı unutulmamalı.Hele dış vendor ücretlendiriyorsa istek/adediyle — faturaya dikkat! Tamamen zincire bağımlısın;Arada biri çökünce tüm akış berhava olur. Kişisel tavsiye: Böyle ortamlarda failover/kesinti planınız mutlaka olsun; Yoksa g

Q: Zincirde Alternatif Modeller ve Tasarım İpuçları B Planı Var mı? Asenkron & Ön-Hazırlıklı Çözümler Bazen “her şey o an canlı olsun!” demek gereksiz pahalı ya da risklidir... Önden hazırlanan cache/ara tablo kullanımı ise tam tersi hız sağlar ama en güncel bilgiyi kaçırabilirsin. Mesela geçen ay hibrit modelde sabah-akşam batch job’larla topluca depolardan bilgi çekip ara tabloda sakladık – sorgular jet gibi çalıştı; ama acil stok değişikliğini birkaç dakika geç gösterdik diye müşteri servisine ekstra yük bindirdik! Her tercihin artısı eksisi var yani... Daha fazla bilgi için VS Code’da MSSQL Eklentisinin 1.40 Güncellemesi... yazımıza bakabilirsiniz. Dikkat Edilecek Noktalar: • Zinciri tamamen uygulama katmanına bırakınca hız kazanılır fakat bakım işleri karmaşa çıkarır. • Veritabanındaki prosedürlerle kurarsanız kontrol sizdedir fakat debug/migration işiniz uzar. • Mesela finans sektöründe politika kısıtlarını hiç küçümsemeyin – kaç defa yolum kesildi saymadım! Pratik örneklerle devam etmek isteyenlere: Polyglot Veritabanı Maliyeti Üzerine Blog Yazım →. Küçük Startup İçin Mi Enterprise’a Göre mi Daha Uygun?

Ekip minikse veya startup’sa,API kompozisyonu çoğu zaman hızlıca çözüme ulaşmanı sağlar. Fakat kurumsal firmalarda yönetmelikler/cross-team kararlar yüzünden genelde iş database katmanına yığılır — Logosoft’taki son projede compliance onayı olmadan taş üstüne taş koyamadık örneğin... Hızlı hareket sevenler için el freni gibiydi!

Q: DAB Chaining’in Pratikte Güzel Yanları ve Sancılı Köşeleri Nerede Parlıyor Nerede Zorluyor?

DAB Chain Avantajları Sıkıntılı Noktalar Hızlı entegrasyonÇeşit çeşit sistemde esneklikKod yükü azalırAPI seviyesinde federasyon desteğiCloud-native uyumlu yapı Her işlem peş peşe gidiyor — paralellik yok Ağda takılan uç noktalar herkesi bekletir Politika nedeniyle debugging kabusa dönebilir Compliance-süreçlerinde evrak trafiği oluşur (Bazı avantajlara kanıp heveslendim zamanında; ama kurum içi network/politika duvarlarına takıldığımda anladım ki gerçek hayatta işler kağıttaki kadar

⏱️ 7 dk okuma📅 26 Mart 2026

“Linked Server” Bitti mi? Modern Çağın Federasyonunu Keşfet

Şöyle ki, Şöyle bir dürüstçe sorayım: Eski “linked server” hikayesini kim unuttu? Zamanında, birleştir, bağla, veri çek – tamam! Hele İstanbul’daki o telekom projesinde şehirlerarası SQL’leri birbirine linked server ile eklediğimde… Ekibin yarısı alkışlamıştı. Kolaydı çünkü; sandığımızdan bile pratik geliyordu. Ama gün geldi devran değişti. Artık veri eskisi gibi sadece tek bir SQL sunucusunda durmuyor; Postgres var orada, Cosmos DB dolaşıyor bulutlarda… Bir de üstüne herkes “bana özel sandbox!” diye tutturunca, eski yöntemler elde kalıyor resmen.

Peki şimdi ne yapacağız? Linked server’a izin yoksa (ya da kullanmak mümkün değilse) farklı veritabanlarından gelen datayı tek yerden kullanıcıya nasıl göstereceğiz? Uygulama geliştiricilerin şemaya dokunması da yasak… Cross-database özelliğini açmak mı? Hayal bile etme!

Zincirin Gücü: Data API Builder ile Pratik Kompozisyon

Birkaç ay önce Logosoft tarafında denk geldim bu mevzuya – büyük bankanın bulut göçü operasyonunda öyle bir tablo vardı ki anlatamam! Milyonlarca ürün kaydı SQL’de tutuluyor ama depo stoğu başka vendor’ın yönettiği Postgres üzerinde ve öneri motorunun çıktısı ise Cosmos DB’ye düşüyor… Lafı dolandırmaya gerek yok: Her şeyden canlı, taze bilgi çekip, tek REST API’dan sunmak şart oldu.

Data API Builder (DAB) burada ciddi fark yaratıyor. Hatta geçen yıl detaylarına şurada değinmiştim. Ama zincirleme kombinasyon kısmı apayrı mesele gerçekten!

💡 Bilgi: DAB sayesinde artık ister klasik SQL ister NoSQL ister modern başka kaynak olsun,
aynı anda sorgu atabiliyorsunuz — kod satırı yazmadan!

Neden DAB Chaining?

Sınırlı erişim: Şema değiştirmene ya izin yok ya da ekip engelliyor mu? Fark etmez, çözülüyor.
Karma platformlar: Veri MS SQL’den çıkıp Postgres’e sapabilir — sıkıntı yaşanmıyor.
Kullanıcı deneyimi: Tek istekle full yanıt alacaksın; hız fena değil!

Zinciri Oluşturmak Kolay mı?

Açık açık söyleyeyim; ilk bakışta kafan biraz karışıyor. “sp_invoke_external_rest_endpoint” fonksiyonu olunca işi direkt veritabanının içinde çevirebiliyorsun.
Eskiden uygulamada call-a-call modeli yapardık ya,
şimdi aynı mantığı SQL prosedürüne gömmek mümkün oluyor.
Garip geliyor başta — alışınca gayet zevkli aslında. Daha fazla bilgi için Azure SQL’de DiskANN Vektör İndeksleri: Gerçekt… yazımıza bakabilirsiniz.

DAB Zincirlemenin Temel Senaryosu: Gerçek Hayattan Bir Örnek

Senenin ilk aylarında e-ticaret müşterisinde pat diye önümüze şöyle bi tablo çıktı:

#	Açıklama	Sistem / Kaynak
1	Katalog & ürün temel bilgisi	MSSQL (DB1)
2	Anlık stok durumu & envanter işlemleri	PostgreSQL (DB2 – dış vendor)
3	Tavsiye edilen benzer ürünler / ilişkiler	Cosmos DB (DB3 – ML output’u)

Tek istekte her kaynaktan zenginleştirilmiş data dönmek gerçek mi hayal mi?
Vallahi oluyor! Yalnız bazı ince detayları ve beklenmedik tuzakları var…

Müşteri dedi ki:
“Kullanıcı ürünü görüyor tamam da, stoğunu canlı bilsin istiyorum;
bir yandan makine öğrenmesiyle gelen benzer ürünleri de sıralayın.”
Güzel dilekler… Fakat stok başka yerde,
öneri bambaşka sistemde geziniyor.
Şimdi sen karar ver:
Tüm parçaları anında toplamak için hangi yolu denersin? Bu konuyla ilgili SQL Server 2025’te JSON Depolama: Artık Sadece … yazımıza da göz atmanızı tavsiye ederim.

Senkron Zincirleme Tasarımı Nasıl İşler?

Tüm İşlem Tek Akışta Gerçekleşiyor mu?

Eğer her şeyi senkron tutacağım diyorsan—yani kullanıcı butona bastığında her kaynaktan gerçek zamanlı cevap gelsin istiyorsan—ilk bakışta kolay görünüyor.
Ama ufak(!) risklere hazır ol…
Bir sistem geciktiğinde domino gibi hepsi yavaşlıyor!


CREATE OR ALTER PROCEDURE dbo.sp_GetProduct
@productId INT,
@userId INT
AS
BEGIN
SET NOCOUNT ON;
— Katalogdan ürünü al (DB1)
— REST endpoint ile depo stoğunu çek (DB2)
— REST endpoint üzerinden önerilen ürünleri çek (DB3)
— Sonuçları şekillendirip döndür
END
GO

Ankara’daki lojistik raporunda ilk defa bunu canlı test ettim – tarih 2019’du yanlış hatırlamıyorsam.
Beklenen oldu:
REST çağrıları arka arkaya sıraya girince ikinci/üçüncü uç noktanın cevabını almadan iş ilerlemiyor.
Yani paralellik sıfır!
Her veri parçası sıradaki kardeşi bitmeden gelmiyor maalesef… Daha fazla bilgi için VS Code’da MSSQL Eklentisinde Neler Değişti? Ya… yazımıza bakabilirsiniz.

Senkron Modelde Karşılaşılan Tuzaklar Nelerdir?

Kritik nokta şu:
süreklilik/freshness vs gecikme/latency dengesi darmadağın olabilir.
Ağ koparsa veya ilgili servis cevap vermezse
Kullanıcının ekranda saat başına dönmesine neden olursunuz ya da eksik datayla ekran dizmek zorunda kalırsınız.
Maliyet detayı unutulmamalı.
Hele dış vendor ücretlendiriyorsa istek/adediyle — faturaya dikkat!

Tamamen zincire bağımlısın;
Arada biri çökünce tüm akış berhava olur.

Kişisel tavsiye:
Böyle ortamlarda failover/kesinti planınız mutlaka olsun;
Yoksa gece vakti telefonunuz susmaz!

Zincirde Alternatif Modeller ve Tasarım İpuçları

B Planı Var mı? Asenkron & Ön-Hazırlıklı Çözümler

Bazen “her şey o an canlı olsun!” demek gereksiz pahalı ya da risklidir…
Önden hazırlanan cache/ara tablo kullanımı ise tam tersi hız sağlar ama en güncel bilgiyi kaçırabilirsin.
Mesela geçen ay hibrit modelde sabah-akşam batch job’larla topluca depolardan bilgi çekip ara tabloda sakladık –
sorgular jet gibi çalıştı;
ama acil stok değişikliğini birkaç dakika geç gösterdik diye müşteri servisine ekstra yük bindirdik!
Her tercihin artısı eksisi var yani… Daha fazla bilgi için VS Code’da MSSQL Eklentisinin 1.40 Güncellemesi… yazımıza bakabilirsiniz.

Dikkat Edilecek Noktalar:
• Zinciri tamamen uygulama katmanına bırakınca hız kazanılır fakat bakım işleri karmaşa çıkarır.
• Veritabanındaki prosedürlerle kurarsanız kontrol sizdedir fakat debug/migration işiniz uzar.
• Mesela finans sektöründe politika kısıtlarını hiç küçümsemeyin – kaç defa yolum kesildi saymadım!

Pratik örneklerle devam etmek isteyenlere:
Polyglot Veritabanı Maliyeti Üzerine Blog Yazım →.

Küçük Startup İçin Mi Enterprise’a Göre mi Daha Uygun?

Ekip minikse veya startup’sa,
API kompozisyonu çoğu zaman hızlıca çözüme ulaşmanı sağlar.
Fakat kurumsal firmalarda yönetmelikler/cross-team kararlar yüzünden genelde iş database katmanına yığılır —
Logosoft’taki son projede compliance onayı olmadan taş üstüne taş koyamadık örneğin…
Hızlı hareket sevenler için el freni gibiydi!

DAB Chaining’in Pratikte Güzel Yanları ve Sancılı Köşeleri

Nerede Parlıyor Nerede Zorluyor?

DAB Chain Avantajları	Sıkıntılı Noktalar
Hızlı entegrasyon Çeşit çeşit sistemde esneklik Kod yükü azalır API seviyesinde federasyon desteği Cloud-native uyumlu yapı	Her işlem peş peşe gidiyor — paralellik yok Ağda takılan uç noktalar herkesi bekletir Politika nedeniyle debugging kabusa dönebilir Compliance-süreçlerinde evrak trafiği oluşur
(Bazı avantajlara kanıp heveslendim zamanında; ama kurum içi network/politika duvarlarına takıldığımda anladım ki gerçek hayatta işler kağıttaki kadar pürüzsüz ilerlemiyor!)

AZ-305 sınavına hazırlanırken kafa patlattığım ilk mimari buydu — konsept çok parlak ama iş pratiğe gelince ağ politikası bazen insana saç baş yolduruyor!

Zincirin Koduna Dalalım mı? Basitleştirilmiş Demo Senaryo!

-- Not : Bu prosedür demo amaçlı sadeleştirildi !
CREATE OR ALTER PROCEDURE dbo.sp_GetProductFullInfo
@productId INT,
@userId INT
AS
BEGIN 
SET NOCOUNT ON;
-- Adım 1 : Ana ürün bilgisini DB1'den getir.
SELECT * FROM Products WHERE ProductId = @productId ;
-- Adım 2 : Depo stoğunu REST üzerinden sorgula.
EXEC sp_invoke_external_rest_endpoint 
@url = 'https://warehouse-vendor/api/inventory/' + CAST(@productId AS VARCHAR),
@method = 'GET',
@headers = '{''Authorization'': ''Bearer xyz...''}' ;
-- Adım 3 : Önerilen ürünleri Cosmos DB'den çek.
EXEC sp_invoke_external_rest_endpoint 
@url = 'https://cosmos-api/products/' + CAST(@productId AS VARCHAR) + '/related',
@method = 'GET';
-- Sonuçları birleşik formatta şekillendirip döndür.
END ;
GO
-- Not : Gerçek dünyada error handling/logging/vb gerekli !

Labaratuvarda oynarken sıkıntısız ilerledi tabii —
Ama prod ortamına geçtiğimiz anda log sayısını artırdık ve hata yönetimini güçlendirdik çünkü network/time-out problemleri er ya da geç mutlaka çıkıyor arkadaşlar…
Hele bir de de cloud’da latency’yi stabilize tutmak ciddi mesele. Burada Azure Monitor’un (bakabilirsiniz buradan 🡕)) yardımı büyük oluyor.

Peki Ya Gelecek? Federation’ın Evrimi Nereye Gidiyor?

No-Code’dan AI Destekliye Yolculuk…

Geliştiriciye dayanan külfet artık iyice servislerin/gömülü araçların omuzuna doğru kayıyor sanki… Hafta başında bir takipçi blogdan yazmıştı:“Abi no-code araçlarla federasyonu hallediyoruz diyebilir miyiz?” Kesin konuşmam zor ama DAB’in yeni sürümlerindeki otomatik şema kurucu/MCP desteklerini görünce umutlandığımı saklayamam. Burada uzun uzun yazdığım gibi; kod derdi azaldıkça IT hayatımız kolaylaşacak galiba… Veya fazla rehavet iyi midir bilmiyorum :)

💡 Bilgi : Büyük regülasyona takılan enterprise projelerde merkezi federasyon kullandığınızda geliştirme hızı %40 civarı artabiliyor—
tabii süreç oturursa ! Tavsiye ederim —
yarın denerseniz sonucu yorumlara bırakın ;)

Sıkça Sorulan Sorular

DAB chaining nedir? Hangi durumlarda kullanılmalı?

DAB chaining dediğimiz yöntem;
çoklu veritabanından ardışık şekilde data toplayıp tek seferde getirmeyi sağlayan pratik federasyon tarzıdır. Linked server yasaksa,
karma teknoloji varsa veya politika sizi boğuyorsa birebir ilaçtır :)

sp_invoke_external_rest_endpoint hangi sürümlerde çalışıyor?

Bu fonksiyon Azure SQL Database’de aktif olarak gelir fakat on-premise klasik SQL Server’da varsayılanda açık değildir. Teknik şartlar/desteklenen sürümler için Microsoft’un dokümantasyonu kesinlikle incelenmeli.

Senkron zincirde performans nasıl etkileniyor?

Her adım sırayla aktığı için herhangi bir uç noktanın yavaşlığı tüm toplam süreyi arttırır —
kritik yerlerde latency dikkat ister,
timeout/hata yakalama iyi kurgulanmalıdır!

Zinciri uygulama yerine neden database tarafında kurmalıyız?

Bazen güvenlik/yetki sorunlarından dolayı uygulamanın erişimi limitliyse federation merkezileşirse çok daha kontrollü olur ama bakım zahmetinin yükseldiğini hesaba katman gerekir! Kendi tecrübelerime göre özellikle finans/regülasyonda şart neredeyse..