yoklateknik mülakat
GelişimGeçmiş

Backend Veritabanı / SQL Mülakat Soruları

75 doğrulanmış Backend Veritabanı / SQL mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Veritabanı / SQLZorluk 1
Bir tablo kolonunda PRIMARY KEY tanımlamak neyi garanti eder?
  • aDeğerler unique olur ama NULL olabilir
  • bDeğerler unique olur ve NULL olamaz✓
  • cDeğerler NULL olamaz ama tekrar edebilir
  • dDeğerler otomatik artan bir sequence ile üretilir
Açıklama:Primary key, uniqueness kısıtı ile NOT NULL kısıtını birleştirir. Otomatik artan değer (d) ayrı bir özelliktir (SERIAL / IDENTITY / AUTO_INCREMENT); primary key ile sık birlikte kullanılsa da primary key'in garantisi değildir.
Veritabanı / SQLZorluk 1
SELECT u.name, o.total FROM users u LEFT JOIN orders o ON o.user_id = u.id sorgusunun sonucunda hangi satırlar yer alır?
  • aSadece en az bir siparişi olan kullanıcılar
  • bSadece geçerli bir kullanıcıya ait siparişler
  • cTüm kullanıcılar; siparişi olmayanlarda sipariş kolonları NULL gelir✓
  • dEşleşme olmasa bile tüm kullanıcılar ve tüm siparişler
Açıklama:LEFT JOIN sol tablonun (users) tüm satırlarını korur. Siparişi olmayan kullanıcılar da sonuçta yer alır, sipariş kolonları NULL döner. (a) INNER JOIN'i, (d) ise FULL OUTER JOIN'e yakın bir davranışı tarif eder.
Veritabanı / SQLZorluk 2
email kolonunda bazı NULL değerler var.
SELECT COUNT(*), COUNT(email) FROM users;

İki sayım arasındaki fark nedir?
  • aHer zaman eşittirler
  • bCOUNT(*) tüm satırları sayar; COUNT(email) email'i NULL olan satırları atlar✓
  • cCOUNT(email) NULL'ları da sayar ama tekrar eden email'leri yok sayar
  • dCOUNT(*) tüm kolonları okumak zorunda olduğu için daha yavaştır
Açıklama:Aggregate fonksiyonlara kolon argümanı verildiğinde NULL değerler yok sayılır; COUNT(email) yalnızca email'i dolu satırları sayar. COUNT(*) satırları sayar ve tüm kolonları okuması gerekmez — (d) yaygın bir efsanedir. Tekrarları yok saymak için COUNT(DISTINCT email) gerekirdi, bu yüzden (c) yanlıştır.
Veritabanı / SQLZorluk 2
GROUP BY kullanan bir sorguda WHERE ile HAVING arasındaki fark nedir?
  • aWHERE satırları gruplamadan önce filtreler; HAVING grupları aggregation sonrası filtreler✓
  • bHAVING satırları gruplamadan önce filtreler; WHERE aggregate sonuçları filtreler
  • cSorguda GROUP BY olduğu sürece ikisi birbirinin yerine kullanılabilir
  • dWHERE sadece index'li kolonlarda çalışır; HAVING her kolonda çalışır
Açıklama:WHERE önce çalışır ve satırları gruplanmadan önce eler. HAVING aggregation'dan sonra çalışır; bu sayede COUNT(*) veya SUM(total) gibi aggregate sonuçlara göre filtreleme yapabilir. Index durumu (d) hangi clause'un kullanılacağıyla ilgisizdir.
Veritabanı / SQLZorluk 2
SELECT department, name, COUNT(*)
FROM employees
GROUP BY department;

Bu sorgu PostgreSQL'de çalıştırıldığında ne olur?
  • aDepartman başına bir satır döner, name kolonuna rastgele bir değer seçilir
  • bHer çalışan, departmanının satır sayısıyla birlikte döner
  • cHata verir: name ne GROUP BY'da ne de bir aggregate fonksiyonun içinde✓
  • dHata verir: COUNT(*) başka kolonlarla birlikte SELECT edilemez
Açıklama:Standart SQL, SELECT edilen her kolonun ya GROUP BY'da ya da bir aggregate içinde olmasını ister; PostgreSQL bunu katı uygular ve name için hata verir. (a) seçeneği MySQL'in eski gevşek modunu (ONLY_FULL_GROUP_BY kapalı) tarif eder; (d) yanlıştır çünkü COUNT(*) doğru gruplanmış kolonlarla sorunsuz kullanılır.
Veritabanı / SQLZorluk 2
PRIMARY KEY ve UNIQUE kısıtlarıyla ilgili hangi ifade doğrudur?
  • aBir tabloda birden çok primary key olabilir ama tek bir unique kısıt olabilir
  • bUNIQUE, primary key gibi NOT NULL anlamına da gelir
  • cPrimary key tek kolon olmak zorundadır; UNIQUE birden çok kolona yayılabilir
  • dBir tabloda tek primary key olur ama birden çok unique kısıt olabilir✓
Açıklama:Bir tabloda en fazla bir primary key olur (composite olabilir, bu yüzden (c) yanlış); UNIQUE kısıtlardan ise istenildiği kadar tanımlanabilir. UNIQUE, primary key'in aksine NOT NULL garantisi vermez, bu yüzden (b) yanlıştır.

Uzmanlığa göre

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

Kıdeme göre

Backend JuniorBackend MidBackend Senior

Diğer alanlar

FrontendFullstackDevOps / CloudAI EngineerVeritabanıMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

3300 soruluk Backend bankasında kendini sına.

Mülakata başla