AI Apps | The .NET Blog

SQL Server 2025 ajanlara hazır veritabanı olarak: güvenlik, yedekleme ve MCP tek bir motorda

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrildi. Orijinal versiyon için buraya tıklayın.

Aditya Badramraju’nun Polyglot Tax serisini büyük bir ilgiyle takip ettim. 1-3. bölümler, SQL Server 2025’i gerçekten çok modelli bir veritabanı olarak güçlü biçimde savundu — JSON, graph, vector ve ilişkisel veriler tek bir motorda, birleşik bir query planner ile. 4. bölüm, bu mimariye production’da gerçekten güvenip güvenmeyeceğinizi belirleyen kısmı kapatıyor.

Spoiler: production hikayesi sağlam.

Tüm Veri Modelleri İçin Tek Güvenlik Modeli

Poliglot stack’lerin sorunu şu: bir denetçi “Tenant A’nın Tenant B’nin verisini göremediğini kanıtla” dediğinde, bu soruya her veritabanı için ayrı ayrı cevap vermen gerekir. Beş veritabanı, beş güvenlik modeli, beş kanıt.

SQL Server 2025 ile tek bir Row-Level Security policy tanımlarsınız ve bu tüm veri modellerini kapsar:

CREATE FUNCTION dbo.fn_TenantFilter(@TenantID INT)
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS fn_result
WHERE @TenantID = CAST(SESSION_CONTEXT(N'TenantID') AS INT);

CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Customers, -- Relational
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Events, -- JSON data
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Relationships, -- Graph edges
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Embeddings -- Vector data
WITH (STATE = ON);

O noktadan sonra her query — ilişkisel join’ler, JSON path sorguları, graph traversalları, vector similarity aramaları — otomatik olarak tenant’a göre filtrelenir. Motor, storage’dan herhangi bir veri çıkmadan önce predicate’i execution plan’a enjekte eder. Çağıran kodunuzun her yere WHERE TenantID = @id yazmasına gerek kalmaz. Policy’yi bir kez test edersiniz.

Katmanlar da birbirini tamamlar: bazı rollerin tam değerleri görmemesi gereken kolonlar için Dynamic Data Masking, uçtan uca şifreleme için Always Encrypted (DBA’lar bile okuyamaz), ve ajanların yalnızca açıkça expose ettiğiniz şeyleri çağırması için izin sınırı olarak stored procedure’ler.

Bu, compliance ağırlıklı SaaS için mimarinin en önemli kısmıdır. Tek policy, tek kanıt.

Birleştirilmiş Yedekleme = Atomik Kurtarma

Tek bir komut, tüm veri modelleri, tutarlı bir zaman noktası:

BACKUP DATABASE MultiModelApp
TO URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH COMPRESSION, ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert);

RESTORE DATABASE MultiModelApp
FROM URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH STOPAT = '2026-02-01 10:30:00';

Poliglot bir stack’te beş veritabanı boyunca point-in-time recovery yapmak, beş restore işlemini koordine etmek ve timestamp’lerin bir iki saniye içinde hizalanmasını ummak demektir. Finansal veri için bu iki saniyelik tutarsızlık kabul edilemez. Tek veritabanı, tek transaction log, tek restore — recovery tanım gereği atomiktir.

Kurcalamaya Dayanıklı Denetim İzleri için Ledger Tabloları

Düzenlemeye tabi sektörlerde “loglarımız var” demek yetmez. Bu logların değiştirilmediğine dair kriptografik kanıta ihtiyacınız vardır:

CREATE TABLE FinancialTransactions (
 TransactionID INT PRIMARY KEY,
 AccountID INT NOT NULL,
 Amount MONEY NOT NULL,
 TransactionType NVARCHAR(20),
 TransactionDate DATETIME2 DEFAULT SYSUTCDATETIME()
)
WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);

Her insert, update ve delete, blockchain benzeri bir yapıya kriptografik olarak hash’lenir. Bir satırın yazıldığı andan beri manipüle edilmediğini bir denetçiye matematiksel olarak kanıtlayabilirsiniz. Poliglot stack’te bu yetenek tüm veritabanlarınızda aynı şekilde mevcut değildir.

MCP Entegrasyonu: Elle Kodlanmış Middleware Olmadan Agent’lar

Seri tam olarak buraya doğru ilerliyordu: SQL Server 2025, SQL MCP Server’ı doğrudan destekliyor; yani agent’larınız her işlem için middleware yazmadan doğal dil tool call’larıyla veritabanını çağırabiliyor.

Bunu stored procedure’leri izin sınırı olarak kullanmak ve Row-Level Security’yi motor seviyesinde uygulamak ile birleştirdiğinizde şu modeli elde edersiniz:

Agent bir tool çağırır, örneğin “12345 hesabı için müşteri bağlamını getir”
MCP bunu tanımladığınız stored procedure’e çevirir
SQL engine tenant izolasyonunu ve column masking’i otomatik uygular
Agent yalnızca görmeye yetkili olduğu veriyi alır

Middleware katmanı yok. Ad-hoc query injection riski yok. Authorization’ı agent değil, engine yönetir.

Bunun .NET Geliştiricileri İçin Önemi

Eğer .NET servisleri geliştiriyor ve SQL Server’ı birincil veri deposu olarak kullanıyorsanız, bu serinin mesajı şu: caching için Redis, ilişkiler için graph database, embeddings için vector store eklemenize gerek yok. SQL Server 2025 bunların hepsini halleder — poliglot bir stack’ten daha iyi operasyonel tutarlılıkla ve gerçekten denetlenebilir birleşik güvenlikle.

MCP entegrasyonu, Semantic Kernel agent’larınızın veya Microsoft Agent Framework workflow’larınızın aynı SQL MCP Server üzerinden veri katmanınızla etkileşime girebileceği, insan sorgularına uygulayacağınız aynı güvenlik garantileriyle çalışabileceği anlamına gelir.

Kapanış

Polyglot Tax serisi baştan sona okunmaya değer. 1-3. bölümler query planner hikayesini kanıtlıyor. 4. bölüm production hikayesini kanıtlıyor. Azure SQL üzerinde agent-first veya AI-augmented uygulamalar geliştiren .NET geliştiricileri için bu mimari ciddi biçimde düşünülmeyi hak ediyor.

Aditya Badramraju’nun orijinal yazısı: The Polyglot Tax – Part 4.

Copilot'a Günde 68 Dakika Kodu Yeniden Açıklamak mı? Bir Çözümü Var

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Copilot oturumunuz /compact‘e ulaştığında ve agent yaptığınız işi tamamen unuttuğunda o anı biliyor musunuz? Sonraki beş dakika dosya yapısını, başarısız testi ve daha önce denediğiniz üç yaklaşımı yeniden açıklarsınız. Sonra bu tekrar olur. Ve yine.

Desi Villanueva bunu ölçtü: günde 68 dakika — yalnızca yeniden yönlendirme için. Kod yazmak için değil. PR incelemek için değil. Sadece AI’ı zaten bildiği şeylerle yeniden hizalamak için.

Bunun neden olduğunu ve bunun için somut bir çözüm bulunduğunu ortaya koyuyor.

Bağlam Penceresinin Yalanı

Agent’iniz kutuda büyük bir sayı ile geliyor. 200K token. Kulağa devasa geliyor. Pratikte bu bir tavan, garanti değil.

İşte gerçek matematik:

Toplam 200K context
Başlangıçta yüklenen MCP araçları için yaklaşık 65K eksik (~33%)
AGENTS.md veya copilot-instructions.md gibi instruction dosyaları için yaklaşık 10K eksik

Böylece size yaklaşık 125K kalıyor, daha ilk kelimeyi yazmadan önce. Ve durum daha da kötü — LLM’ler context doldukça düzgün şekilde degrade olmaz. Yaklaşık %60 kapasitede duvara çarparlar. Model, 30 tur önce söylenen şeyleri kaybetmeye başlar, önceki cevaplarla çelişir ve 10 dakika önce güvenle söylediği dosya adlarını halüsinasyon olarak üretir. Sektör buna “lost in the middle” problemi diyor.

Etkin sınır: kalite düşmeye başlamadan önce 45K token. Bu da muhtemelen agent’in kaymaya başlamasından önce sadece 20-30 aktif konuşma turu demek. Bu yüzden /compact‘e her 45 dakikada bir gidiyorsunuz — 200K token doldurduğunuz için değil, model 120K’de zaten bozulmaya başladığı için.

Compaction Vergisi

Her /compact akış durumunuzu alır götürür. Derin bir debug oturumundasınız. Paylaşılan context 30 dakikadır oluşuyor. Agent dosya yapısını, başarısız testi ve hipotezi biliyor. Sonra uyarı geliyor.

Görmezden gelin → agent giderek aptallaşır ve eski state’i halüsinasyonla doldurmaya başlar
/compact çalıştırın → agent’a 30 dakikalık bir incelemenin iki paragraflık özeti verilir

Her iki durumda da kaybedersiniz. Her iki durumda da projenizi ilk günündeki yeni bir çalışana anlatıyormuşsunuz gibi yeniden anlatırsınız.

Kötü tarafı? Memory zaten var. Copilot CLI her oturumu ~/.copilot/session-store.db içindeki yerel bir SQLite veritabanına yazar — dokunulan her dosya, her tur, her checkpoint. Hepsi diskte duruyor. Agent sadece okuyamıyor.

auto-memory: bir recall katmanı, memory sistemi değil

auto-memory’nin arkasındaki ana fikir bu: yeni bir memory sistemi kurmayın — zaten var olanın üstüne yalnızca okunabilir bir query katmanı kurun.

pip install auto-memory

Yaklaşık 1.900 satır Python. Sıfır bağımlılık. 30 saniyede kurulur.

Context’i grep sonuçlarıyla doldurmak yerine, agent’e gerçekten önemli olana cerrahi erişim verirsiniz:

İşlem	Token	Ne elde edersiniz
`grep -r "auth" src/`	~5,000–10,000	500 sonuç, çoğu alakasız
`find . -name "*.py"`	~2,000	Tüm Python dosyaları, contextsiz
Agent yeniden yönlendirme	~2,000	Ona zaten bilmesi gereken şeyi siz anlatırsınız
`auto-memory files --json --limit 10`	~50	Dün üzerinde çalıştığınız 10 dosya

Bu 200x iyileşme demek. Agent arkeolojik kazıyı atlar ve doğrudan önemli olana gider.

Önerilen akış: context kullanımınız %50-70’e yaklaşınca /clear çalıştırın ve ardından şunu yazın: “X konusunu tartıştığımız son oturumları incele”. Kör aramalara 12K token harcamak yerine, auto-memory ilgili context’i 50 token içinde çeker.

Bu .NET Geliştiricileri İçin Neden Önemli

GitHub Copilot CLI’ı .NET işleri için kullanıyorsanız — servisler scaffold etmek, EF Core sorgularını debug etmek, Blazor bileşenleri üzerinde yinelemek — context rot problemi size de aynı sertlikle çarpar. Birden fazla proje, paylaşılan kütüphaneler ve derin call chain’ler içeren karmaşık çözümler, agent’in en hızlı yolunu kaybettiği codebase türüdür.

Kurulum kılavuzu Copilot CLI’ı buna nasıl yönlendireceğinizi anlatıyor. Bu tek seferlik bir kurulum.

Dürüst olmak gerekirse? Günde 68 dakikayı geri kazanmak küçük bir yaşam kalitesi ayarı değil. Bu haftada neredeyse 6 saat eder.

Kapanış

Context rot gerçek bir mimari kısıt, sonradan patch’lenecek bir bug değil. auto-memory, agent’inize pahalı ve gürültülü yeniden keşif yerine ucuz ve kesin bir recall mekanizması vererek bunu aşıyor. GitHub Copilot CLI ile ciddi AI destekli geliştirme yapıyorsanız, 30 saniyelik kurulum buna değer.

Göz atın: GitHub’da auto-memory. Desi Villanueva’nın orijinal yazısı: I Wasted 68 Minutes a Day Re-Explaining My Code.