ORM (Nesne-İlişkisel Eşleme)

Bir ORM (Nesne-İlişkisel Eşleyici / Object-Relational Mapper), ilişkisel bir veritabanının tablo ve satırları ile bir uygulamanın kendi nesneleri ve sınıfları arasında çeviri yapan bir kütüphanedir; geliştiricilerin her sorgu için elle SQL yazmak yerine `User.where(email: "a@b.com")` ya da `$user->posts()->where('published', true)->get()` gibi ifadeler yazmasını sağlar. AI/SaaS geliştiricileri için neden önemli: ORM'ler (Laravel'de Eloquent, Node/TypeScript ekosisteminde Prisma ve Drizzle, Python'da SQLAlchemy, Rails'te ActiveRecord) modern SaaS backend'lerinin büyük çoğunluğunun veritabanıyla günlük olarak etkileşim kurma biçimidir; çünkü geliştirmeyi ciddi şekilde hızlandırır, tip güvenliği sağlar (özellikle veritabanı şemasından doğrudan TypeScript tipleri üreten Prisma ve Drizzle) ve şema migration'larını merkezileştirir. AI özellikleri açısından, bir `User` veya `Document` satırını temsil eden aynı ORM modelleri genellikle `embedding` sütununu da (pgvector aracılığıyla) taşır ve yapılandırılmış iş verisini vektör arama sonuçlarıyla tek bir yerde birleştiren ilişkileri de içerir. Nasıl çalışır: bir ORM her veritabanı tablosunu bir sınıfa/modele, her satırı o sınıfın bir örneğine, her sütunu ise bir özelliğe (property) eşler — ve metot zincirlerini veya sorgu oluşturucu (query builder) sözdizimini arka planda veritabanına gönderilen gerçek SQL'e çevirir. Bu kolaylığın iyi bilinen bir başarısızlık modu vardır: N+1 sorgu problemi. Bir nesne listesi üzerinde saf bir döngü kurup her birinde ilişkili bir nesneye erişmek (örneğin bir Ruby `posts.each { |p| p.author.name }` bloğu), tek bir verimli join veya toplu sorgu yerine her iterasyonda bir sorgu tetikler — 10 satırlık bir demoda görünmezken, üretimde 10.000 satırda felakete dönüşür. Olgun ORM'lerin çoğu, geliştiricilerin ilişkili veriyi toplu şekilde çekmeyi tercih edip bu tuzaktan kaçınmasını sağlamak için özellikle eager-loading sözdizimi sunar (Eloquent'te `.with('author')`, Prisma'da `include`). Somut örnek: Bir yapay zeka destekli proje yönetimi SaaS'ının dashboard endpoint'i 200 görev üzerinde döngüye girer ve her biri için atanan kişinin adını ayrı ayrı sorgular — toplam 201 veritabanı gidiş-dönüşü ve endpoint 4 saniyede yanıt verir. Sorguyu eager loading ile yeniden yazmak — `Task::with('assignee')->where('project_id', $id)->get()` — bunu toplam 2 sorguya indirir (biri görevler için, biri tüm atananlar için toplu sorgu) ve aynı endpoint 100 milisaniyenin altında yanıt döner. N+1 problemi özellikle vurgulanmaya değer, çünkü ORM'ler bunu tamamen deyimsel görünen bir kodda kazara yazmayı kolaylaştırır — bir döngü içindeki `p.author.name` ifadesi okurken hiçbir şekilde performans hatası gibi görünmez; ekiplerin bunu manuel bir kod okumasında fark etmeye güvenmek yerine, bunu code review sırasında yakalamak için otomatik N+1 tespit araçları (Laravel'in üretim dışı ortamlarda kullanılan `preventLazyLoading()` metodu gibi) eklemesinin nedeni de tam olarak budur.