Kendi başına yapabilir misin?

Hat 06'nın yeterliliğinde entegre edilebilir bir API sözleşmesi üretmiş ve "servisi silme, Hat 07'de gerçek veritabanına bağlayacaksın" denmişti. Sırası geldi. Bu hattın kapanış görevi tablo oluşturmak değil: şemayı tasarlamak, sorguları ölçmek, eşzamanlılığı yönetmek ve şemayı canlıyken değiştirebilmek. Bu hat, iki ilanın da en ağır ortak maddesidir — İlan A'da "Veritabanı ve SQL bilgisi", İlan B'de "SQL ve veritabanı tasarım prensipleri" ve "İlişkisel veritabanları". Kural aynı: görevi derslere bakmadan tamamlayamıyorsan hat bitmemiştir.

01Bu hat sana ne kazandırmış olmalı

02Görev — Servisi gerçek veritabanına bağla

Başlangıç noktan Hat 06'nın yeterliliğinde ürettiğin API'dir. O kodu bulamıyorsan önce onu yeniden kur — bu görevin ön koşuludur. Süre beklentisi 180-210 dakikadır. Oturum kapalı kitaptır: derslere ve internete bakmak yok; editörün tamamlama listesi, derleyici, --help çıktıları ve veritabanı hata mesajları serbest.

Değişmez kural: API sözleşmesi değişmeyecek. Hat 06'da tasarladığın uçlar, durum kodları ve hata biçimi aynı kalacak; bu görevin tamamı sözleşmenin arkasında geçiyor. Başlamadan önce iki motoru da ayağa kaldır (PostgreSQL zorunlu, SQL Server mümkünse) ve ölçümlerini kaydedeceğin bir olcum.md dosyası aç.

1. Şemayı tasarla (8. ders): en az altı tablo kur — müşteri, sipariş, sipariş satırı, ürün, etiket ve ürün-etiket bağlantısı. Her tabloda vekil birincil anahtar, doğal anahtarda UNIQUE, uygun NOT NULL ve CHECK kısıtları bulunsun. Kararlarını yaz: anahtar tipi neden int/bigint/GUID, hangi ilişkide ON DELETE ne, hangi sütun neden nullable.
2. 3NF'i savun (8. ders): şemanı normal biçimler açısından denetle ve bilinçli bıraktığın her denormalizasyonu gerekçelendir. Sipariş satırında ürünün o günkü fiyatını sakladığını ve nedenini yaz.
3. Hesaplanmış sütun (8. ders): satır toplamını PERSISTED / GENERATED ... STORED ile kur ve doğrudan güncellemeyi deneyerek motorun tepkisini kaydet.
4. Veri üret: en az 500 000 sipariş ve 2 milyon sipariş satırı üret. Dağılım eşitsiz olsun: bir müşteride 100 000 sipariş, çoğunda 2-3; durum sütununun %98'i "Tamamlandı".
5. Sorguları yaz (2-7. dersler): API'nin ihtiyaç duyduğu sekiz sorguyu önce ham SQL olarak yaz: tekil getirme, filtreli liste, şehir bazlı ciro raporu, müşteri başına son sipariş, en çok satan ilk 10 ürün, gruplandırılmış aylık trend (pencere fonksiyonuyla yürüyen toplam), etikete göre ürün arama, hiyerarşik kategori listesi (özyinelemeli CTE).
6. Ölç ve indeksle (9. ders): her sorgu için SET STATISTICS IO / EXPLAIN (ANALYZE, BUFFERS) çıktısını al ve mantıksal okuma sayısını olcum.md'ye yaz. Sonra indeksleri tasarla ve ölçümü tekrarla. Her indeks için tek cümlelik gerekçe yaz; kapsayan indeks kullandığın yeri işaretle.
7. SARGability sınavı (9. ders): sorgularından birini bilerek SARGable olmayan hâle getir (tarih üzerinde YEAR(), sütunda aritmetik, örtük tip dönüşümü) ve plan farkını kaydet. Sonra düzelt.
8. Sayfalamayı ölçekle (2. ders, 6. hat): koleksiyon ucunu önce OFFSET/FETCH ile, sonra imleç (keyset) yaklaşımıyla kur; 25 000. sayfada iki yöntemin süresini karşılaştır. Kararlı sıralama uyguladığını kanıtla.
9. Transaction sınırını kur (10. ders): sipariş oluşturma akışını tek transaction'da yaz — sipariş, satırlar ve stok düşümü. XACT_ABORT / savepoint davranışını deneyerek doğrula: ikinci adım hata verdiğinde ilki geri alındı mı?
10. Eşzamanlılığı kanıtla (10. ders): iki oturumdan aynı ürünün stoğunu düşür ve kayıp güncellemeyi üret. Sonra rowversion/xmin ile iyimser denetim ekleyip aynı senaryoda 409/412 döndüğünü göster. Ayrıca bir deadlock üret, hata numarasını kaydet ve erişim sırasını sabitleyerek çöz.
11. Kuyruk deseni (10. ders): sipariş sonrası e-posta işini SKIP LOCKED / READPAST ile çeken iki işçi yaz ve aynı satırı iki kez almadıklarını kanıtla. Bu işi transaction içinde göndermediğini, outbox'a yazdığını göster.
12. Görünüm ve nesneler (11. ders): soft delete filtresini bir görünümde topla. Şehir bazlı ciro özetini SQL Server'da indeksli görünüm, PostgreSQL'de materyalize görünüm olarak kur; SQL Server'ın reddettiği en az üç yapıyı ve hata mesajlarını olcum.md'ye yaz. PostgreSQL'de CONCURRENTLY tazelemeyi çalıştır.
13. Motor farkını belgelendir (12. ders): yazdığın sekiz sorgudan kaçının iki motorda değişmeden çalıştığını say; değişenler için farkı tek satırda yaz.
14. PostgreSQL'i işlet (13. ders): psql ile bağlan; uygulama için ayrı bir rol ve şema oluştur, ALTER DEFAULT PRIVILEGES ayarla. Ürün niteliklerini jsonb sütununda tut, GIN indeksiyle sorgula ve indeksli/indekssiz süreyi karşılaştır. Ardından bol güncelleme yapıp n_dead_tup ile tablo boyutunu izle, VACUUM etkisini kaydet ve age(datfrozenxid) değerini oku.
15. Uygulamaya bağla (15. ders): API'yi EF Core ile veritabanına bağla. Bağlam ömrünü doğru kur, eşleme yapılandırmalarını akıcı API ile ayrı sınıflara al, decimal hassasiyetini ve UTC davranışını ayarla. Üretilen SQL'i logla.
16. Göçe geç (16. ders): şemayı göçlerle yönet ve --idempotent SQL üret. Ardından genişlet–taşı–daralt ile bir sütunu dönüştür (Sehir metnini SehirId yabancı anahtarına) ve dört adımın göçlerini yaz.
17. N+1'i üret ve kes (16. ders): liste ucunda tembel yüklemeyle N+1 oluştur, log'dan sorgu sayısını say. Sonra projeksiyon ve Include ile çöz; iki koleksiyonu birden çekip Kartezyen patlamayı gör ve AsSplitQuery ile düzelt. Üç yaklaşımın sorgu sayısı, dönen satır ve süresini tabloya yaz.
18. Toplu işi doğru yap (5, 16. dersler): 200 000 siparişi arşivlemeyi önce nesne döngüsüyle, sonra ExecuteUpdate ile yap; süreleri karşılaştır ve işi partilere bölerek kilit yükseltmesinden kaçındığını göster.
19. Raporu Dapper'a taşı (17. ders): en ağır iki raporu Dapper ile yaz; QueryMultiple ile gösterge paneli sayfasını tek gidiş-gelişte doldur. EF Core transaction'ını Dapper'a geçirerek ikisini tek atomik işte çalıştır.
20. Alternatifi tart (18. ders): ürün kataloğunu MongoDB'de modelleyip yarım sayfa yaz: neyi gömerdin, neyi referans verirdin, hangi indeksleri açardın (ESR), hangi tutarlılık garantisini kaybederdin. İstersen küçük bir koleksiyon kurup aynı arama sorgusunu çalıştır ve jsonb sürümüyle karşılaştır.
21. Yedeği dene (13. ders): pg_dump -Fc ile yedek al, veritabanını düşür, pg_restore ile geri yükle ve API'nin çalıştığını doğrula. Geri yükleme süresini yaz.
22. Sınırı savun (4. hat): açtığın her indeksi gözden geçir; ölçümle gerekçelendiremediğin her indeksi kaldır. Bu madde puanlıdır: her yeteneği kullanmak değil, gerekmeyeni kullanmamak da ölçülüyor.
23. Değerlendirme: takıldığın maddeleri aşağıdaki tablodan derslerine eşle, yalnız o dersleri çalış ve 24 saat sonra görevi baştan yap — düzeltme değil, sıfırdan. Eşik: tüm maddeler yardımsız, her sorgunun ölçümü kayıtlı, eşzamanlılık senaryoları kanıtlı ve göçler tek komutla uygulanabilir durumda.

Bitirdiğinde elinde üretime yakın bir veri katmanı olacak: şeması gerekçeli, sorguları ölçülmüş ve indekslenmiş, transaction sınırları belirli, eşzamanlılık çakışmalarını sessizce yutmayan, şeması sürüm kontrolünde ve canlıyken değiştirilebilen bir sistem. Bu katman 13. hatta yetkilendirmeyle korunacak, 15. hatta entegrasyon testleriyle sabitlenecek, 17. hatta kapsayıcıya alınacak, 18. hatta göçleri otomatik uygulanacak ve 19. hatta önbellek ile mesajlaşma eklendiğinde asıl sınavını verecek.

03Kontrol listesi

Her satırı kendine sorarak işaretle; "evet" diyemediğin satırın dersine dön.

04Sözlü provası

Aşağıdaki dört soruyu, cevabı açmadan önce sesli cevapla. Dördü de iki ilanın ortak maddelerinden gelir ve mülakatta neredeyse kesin sorulur.

Normalizasyon nedir, kaçıncı normal biçimde durursunuz?

Bulunması gerekenler: normalizasyonun amacı estetik değil, tekrar eden verinin ürettiği güncelleme, ekleme ve silme anomalilerini engellemektir; temeli fonksiyonel bağımlılıktır. Kural tek cümlede toplanır: her anahtar dışı sütun anahtara (1NF), tüm anahtara (2NF) ve yalnızca anahtara (3NF) bağlı olmalıdır. 1NF her hücrede tek ve bölünemez değer ister; 2NF yalnızca bileşik anahtarlı tablolarda anlamlıdır ve vekil anahtarlı tabloda tanım gereği ihlal edilemez; 3NF geçişli bağımlılığı yasaklar; BCNF ise aday anahtarların örtüştüğü durumu kapatır. Cevap: OLTP şemasında 3NF/BCNF'te dururum, raporlamada yıldız şemasıyla bilinçli olarak denormalize ederim. Kıdem sinyalleri: "denormalizasyonu ölçtükten sonra yaparım ve elle güncellemek yerine hesaplanmış sütuna bırakırım — PERSISTED ya da GENERATED ... STORED"; "sipariş satırındaki fiyat gibi tarihsel değerleri kopyalarım, çünkü onlar zamanda dondurulmalıdır, bu denormalizasyon değil doğru modellemedir"; "birincil anahtarı vekil seçerim ama doğal anahtarı UNIQUE ile korurum, çünkü iş dünyasındaki tanımlayıcılar değişir"; "EAV ve virgüllü liste gibi anti-desenlerden kaçınırım, gerçekten dinamik veri varsa jsonb kullanırım".

İndeks nedir, nasıl çalışır? Bir sorgunun neden yavaş olduğunu nasıl bulursunuz?

Bulunması gerekenler: indeks, aranan sütunlara göre sıralı tutulan bir B-ağacıdır; sayfaya yüzlerce anahtar sığdığı için ağaç 3-4 seviyedir ve tek satır birkaç sayfa okumasıyla bulunur — kazanç daha iyi bir algoritmadan değil, G/Ç'nin azalmasından gelir. SQL Server'da clustered indeks tablonun kendisidir ve nonclustered indeksler satıra clustered anahtarla işaret eder; PostgreSQL'de clustered indeks yoktur, tüm tablolar heap'tir. Tasarım kuralı: WHERE/JOIN/ORDER BY sütunları anahtara, yalnız döndürülenler INCLUDE'a; eşitlik önce, aralık sonra. Teşhis yöntemi ölçmektir: SET STATISTICS IO ya da EXPLAIN (ANALYZE, BUFFERS) ile mantıksal okuma sayısına bakarım, süreye değil. Planda ilk baktığım şey tahmini ile gerçek satır sayısı arasındaki sapmadır; büyük sapma genelde eskimiş ya da yetersiz istatistiktir. Sonra key lookup, gereksiz Sort, diske taşma ve Filter işlemcisine bakarım. Kıdem sinyalleri: "'indeks var ama kullanılmıyor' denince önce SARGability'ye ve örtük tip dönüşümüne bakarım"; "SQL Server histogramı 200 adımla sınırlıdır, artan anahtarda tahmin bozulur"; "parametre koklaması yüzünden aynı prosedür bazen hızlı bazen çok yavaş çalışır, PostgreSQL'de karşılığı beşinci çalıştırmadan sonra genel plana geçilmesidir"; "her indeks yazmayı yavaşlatır, DMV önerilerini körü körüne uygulamam".

Transaction ve izolasyon seviyelerini anlatın. Deadlock'ı nasıl önlersiniz?

Bulunması gerekenler: transaction ya hep ya hiç çalışan işlem grubudur; ACID'in dört güvencesi ve kalıcılığın önce günlüğe yazma ile sağlandığı — commit anında veri sayfaları değil işlem günlüğü diske iner. Yalıtım, ACID'in ayarlanabilir tek harfidir; seviyeler sırasıyla kirli okuma, tekrarlanamaz okuma ve hayaleti kapatır. Kritik ayrım: iki motor da READ COMMITTED der ama SQL Server bunu kilitle, PostgreSQL MVCC ile yapar — SQL Server'da güncellenen satırı okumak için beklersiniz, PostgreSQL'de beklemezsiniz; SQL Server'da bu davranış RCSI ile açılır ve bedeli tempdb sürüm deposudur. Deadlock, döngüsel bekleyiştir ve engellenmeden farklıdır; motor birini kurban seçer (SQL Server 1205, PostgreSQL 40P01). Önleme sırası: nesnelere her yerde aynı sırada erişmek, transaction'ı kısa tutmak (içine ağ çağrısı ve kullanıcı etkileşimi koymamak), doğru indeks açmak — indeks bir eşzamanlılık aracıdır, çünkü indekssiz UPDATE ilgisiz satırları da kilitler — ve kalanı için artan beklemeli yeniden deneme yazmak. Kıdem sinyalleri: "yeniden denemede transaction'ın tamamını baştan çalıştırırım"; "PostgreSQL'in SERIALIZABLE'ı kilitlemez, 40001 ile düşürür, yani retry zorunludur"; "SQL Server yaklaşık 5000 kilitte tabloya yükseltir, bu yüzden büyük DML'i partilere bölerim"; "uzun açık transaction PostgreSQL'de VACUUM'u durdurup tabloları şişirir, idle_in_transaction_session_timeout ayarlarım"; "kullanıcı ekranı arkasındaki güncellemede rowversion ile iyimser denetim kurarım".

ORM kullanır mısınız? N+1 problemi nedir, nasıl çözersiniz?

Bulunması gerekenler: ORM'in nesne–ilişkisel uyumsuzluğu kapattığı ve beş iş yaptığı (eşleme, SQL üretimi, kimlik haritası, değişiklik takibi, birim iş); ama sızdıran bir soyutlama olduğu — üretilen SQL'i ve planını okumayı gerektirir, yani SQL bilmenin yerine geçmez. N+1: ana listeyi bir sorguyla çekip döngüde her satırın ilişkisine dokunmak 1+N sorgu üretir; her biri hızlı olduğu için yerelde fark edilmez, gecikmeli üretimde ortaya çıkar. Çözümler: projeksiyon (yalnız gereken alanları tek sorguda hesaplatmak — çoğu durumda en iyisi), Include ile erken yükleme, ve koşullu durumlarda açık yükleme; tembel yükleme üretimde genellikle kapatılır. Ama Include'u fazla kullanmak yeni bir sorun doğurur: iki koleksiyonu birlikte çekmek Kartezyen çoğalma üretir, orada AsSplitQuery gerekir. Kıdem sinyalleri: "ORM'i toplu veri işleme, raporlama ve elle ayarlanmış karmaşık sorgularda kullanmam; ExecuteUpdate ile küme SQL'i çalıştırır ya da raporu Dapper'a taşırım"; "yazma tarafı EF Core, ağır okumalar Dapper — ikisi aynı transaction'ı paylaşabilir"; "göçleri uygulama açılışında değil, dağıtım hattının ayrı adımında idempotent SQL olarak uygularım"; "canlı sistemde sütun değişikliğini genişlet–taşı–daralt ile yaparım"; "eşzamanlılık istisnasını yutmam, veritabanındaki güncel hâli okuyup kullanıcıya gösteririm".

05Karar