Hamroh materiallar/Intervyu41 daqiqa

Texnik intervyu: Ma'lumotlar bazasi — SQL, NoSQL, dizayn va optimizatsiya

Ushbu fayl full-stack dasturchi uchun ma'lumotlar bazasi bo'yicha chuqur intervyu tayyorgarligi. SQL va NoSQL, ma'lumotlar modeli, index, tranzaksiya, optimizatsiya va amaliy SQL yozish savollari qamrab olingan.

Kirish

Ma'lumotlar bazasi (database) deyarli har bir backend intervyusining markazida turadi. Intervyu beruvchi sizdan faqat sintaksisni emas, balki nega bir yechim ikkinchisidan yaxshiroq ekanini, ma'lumot qanday saqlanishi va o'qilishini, tizim ko'p foydalanuvchi ostida qanday tutishini tushunishingizni kutadi.

Har bir savol quyidagi tuzilishda berilgan:

Ta'rif — tushuncha nima ekani, aniq va qisqa.
Mexanizm — ichkarida qanday ishlashi, nega shunday.
Kod/SQL misol — amaliy ko'rinishi.
Keng tarqalgan xato — nomzodlar tez-tez qiladigan xatolik.
Follow-up — intervyu beruvchi keyin so'rashi mumkin bo'lgan savol.

Belgilash: Junior · Middle · Senior.

Maslahat: SQL savollarida javobni ovoz chiqarib tushuntiring — intervyuda ko'pincha fikrlash jarayoni javobning o'zidan muhimroq.

1-bo'lim. SQL, NoSQL va ma'lumotlar modeli

S: SQL va NoSQL ma'lumotlar bazasi nima va ular qanday farq qiladi? (Junior)

Ta'rif. SQL (relational) ma'lumotlar bazasi ma'lumotni jadval (table) ko'rinishida, oldindan belgilangan sxema (schema) bilan saqlaydi — masalan PostgreSQL, MySQL. NoSQL — bu relational bo'lmagan bazalar oilasi: document (MongoDB), key-value (Redis), column-family (Cassandra), graph (Neo4j).

Mexanizm. SQL bazada har bir qator (row) ustunlar (column) tiplari qat'iy belgilangan sxemaga bo'ysunadi va ma'lumotlar o'zaro JOIN orqali bog'lanadi. NoSQL ko'pincha sxemasiz (schema-less) yoki moslashuvchan sxema bilan ishlaydi, ma'lumotni bir hujjatga jamlab (denormalized) saqlaydi, shuning uchun gorizontal masshtablanishi (horizontal scaling) osonroq.

Kod/SQL misol:

sql

-- SQL: qat'iy sxemali jadval
CREATE TABLE users (
    id      SERIAL PRIMARY KEY,
    email   VARCHAR(255) UNIQUE NOT NULL,
    age     INT CHECK (age >= 0)
);

javascript

// NoSQL (MongoDB): moslashuvchan hujjat
db.users.insertOne({
  email: "ali@example.com",
  age: 25,
  addresses: [ { city: "Toshkent" } ]   // ichma-ich (nested) tuzilma
});

Keng tarqalgan xato. "NoSQL SQL'dan tezroq" deb umumlashtirish. Tezlik masalaga bog'liq: NoSQL oddiy kalit bo'yicha o'qishda tez, lekin murakkab bog'lanishlar (JOIN) va tranzaksion yaxlitlikda relational baza ustunlik qiladi.

Follow-up. "NoSQL ACID kafolatini bermaydi" degan gap bugungi kunda to'g'rimi? (Zamonaviy MongoDB ko'p-hujjatli tranzaksiyalarni qo'llab-quvvatlaydi, lekin an'anaviy sozlamada u BASE modeliga yaqinroq.)

S: Loyihangizda SQL yoki NoSQL — qaysi birini qachon tanlaysiz? (Middle)

Ta'rif. Tanlov ma'lumotning tuzilishi, o'zaro bog'lanishlari, yaxlitlik talablari va masshtablash modeliga bog'liq.

Mexanizm. SQL'ni tanlaysiz, agar:

ma'lumot qat'iy tuzilishga ega va ko'p bog'lanishlar bor (foydalanuvchi buyurtma to'lov);
tranzaksion yaxlitlik kritik (bank, moliya, inventar);
murakkab hisobotlar, JOIN va aggregatsiya kerak.

NoSQL'ni tanlaysiz, agar:

sxema tez-tez o'zgaradi yoki oldindan noma'lum (loglar, IoT, katalog);
juda katta hajm va gorizontal masshtablash zarur;
o'qish naqshi (access pattern) oldindan aniq va bir hujjatga jamlanadigan bo'lsa (masalan, foydalanuvchi profili + uning sozlamalari).

Kod/SQL misol:

text

Bank tranzaksiyalari    PostgreSQL (ACID, JOIN, aniqlik)
Real-time chat sessiya  Redis (tez, TTL bilan)
Mahsulot katalogi       MongoDB (moslashuvchan atributlar)
Analitika / loglar      ClickHouse / Cassandra (yozuvga ustun)

Keng tarqalgan xato. "Yangi loyiha — demak NoSQL" deb moda ortidan borish. Ko'p startaplar PostgreSQL'da JSONB ustunidan foydalanib, ham relational ham hujjat modelining afzalliklarini bitta bazada oladi.

Follow-up. Bitta loyihada ikkalasini birga (polyglot persistence) ishlatgan holatga misol ayting.

S: Relational model nima — table, row, column, relation? (Junior)

Ta'rif. Relational model — ma'lumotni munosabatlar (relations, ya'ni jadvallar) to'plami sifatida ifodalaydigan model. Uni E. F. Codd 1970-yilda taklif qilgan.

Mexanizm. Har bir jadval (table) — bu relation; har bir qator (row / tuple) — bitta yozuv; har bir ustun (column / attribute) — o'sha yozuvning bir xususiyati. Jadvallar bir-biri bilan kalitlar (key) orqali bog'lanadi. Model to'plamlar nazariyasi va relational algebraga asoslanadi, shuning uchun so'rovlar deklarativ (SELECT ... WHERE ...) yoziladi — "nima kerak"ni aytasiz, "qanday olishni" baza hal qiladi.

Kod/SQL misol:

sql

-- users va orders o'rtasida munosabat
CREATE TABLE users (
    id   SERIAL PRIMARY KEY,
    name VARCHAR(100)
);

CREATE TABLE orders (
    id       SERIAL PRIMARY KEY,
    user_id  INT REFERENCES users(id),  -- relation (bog'lanish)
    amount   NUMERIC(10, 2)
);

Keng tarqalgan xato. "Relation" so'zini "ikki jadval orasidagi bog'lanish" deb tushunish. Relational modelda "relation" — bu jadvalning o'zi; bog'lanish esa "relationship" (foreign key).

Follow-up. One-to-many, many-to-many va one-to-one munosabatlar sxemada qanday amalga oshiriladi?

2-bo'lim. Kalitlar va bog'lanishlar

S: PRIMARY KEY va FOREIGN KEY farqi nima? (Junior)

Ta'rif. PRIMARY KEY — jadvaldagi har bir qatorni noyob aniqlaydigan ustun(lar). FOREIGN KEY — boshqa jadvalning primary key'iga ishora qiluvchi ustun; u referensial yaxlitlikni (referential integrity) ta'minlaydi.

Mexanizm. Primary key ikki shartni bajaradi: UNIQUE (takrorlanmaydi) va NOT NULL (bo'sh bo'lmaydi). Baza uni odatda avtomatik indekslaydi. Foreign key esa qiymati faqat ishora qilinayotgan jadvalda mavjud bo'lgan qiymat bo'lishini majbur qiladi — mavjud bo'lmagan user_id bilan order qo'sha olmaysiz. ON DELETE / ON UPDATE qoidalari bilan xatti-harakat sozlanadi.

Kod/SQL misol:

sql

CREATE TABLE orders (
    id       SERIAL PRIMARY KEY,           -- noyob identifikator
    user_id  INT NOT NULL,
    FOREIGN KEY (user_id)
        REFERENCES users(id)
        ON DELETE CASCADE                  -- user o'chsa, buyurtmalari ham o'chadi
);

Keng tarqalgan xato. Foreign key ustuniga index qo'ymaslik. FK avtomatik indekslanmaydi (primary key indekslanadi), shu sabab bog'langan qatorlarni qidirish sekinlashadi va DELETE operatsiyalari to'liq skan qiladi.

Follow-up. ON DELETE CASCADE, SET NULL va RESTRICT o'rtasidagi farq nima va qachon qay birini tanlaysiz?

S: Composite (tarkibiy) primary key nima va qachon ishlatiladi? (Middle)

Ta'rif. Composite primary key — bir emas, bir necha ustundan tashkil topgan primary key; ustunlar birgalikda noyoblikni ta'minlaydi.

Mexanizm. Ko'pincha many-to-many bog'lanishning oraliq (junction) jadvalida ishlatiladi. Masalan, talaba va kurs orasidagi ro'yxatda (student_id, course_id) juftligi noyob bo'lishi kerak — bir talaba bir kursga ikki marta yozila olmasin. Baza bu juftlik uchun yagona index yaratadi va ustunlar tartibi index samaradorligiga ta'sir qiladi.

Kod/SQL misol:

sql

CREATE TABLE enrollments (
    student_id INT REFERENCES students(id),
    course_id  INT REFERENCES courses(id),
    enrolled_at DATE DEFAULT CURRENT_DATE,
    PRIMARY KEY (student_id, course_id)   -- tarkibiy kalit
);

Keng tarqalgan xato. Ustunlar tartibini o'ylamaslik. PRIMARY KEY (student_id, course_id) indexi student_id bo'yicha qidiruvni tezlashtiradi, lekin faqat course_id bo'yicha qidiruvda ishlamaydi (leftmost prefix qoidasi).

Follow-up. Composite kalit o'rniga sun'iy (surrogate) id ustuni qo'shib, juftlikni UNIQUE constraint qilish qachon afzalroq?

S: Surrogate key va natural key farqi nima? (Middle)

Ta'rif. Natural key — ma'lumotning o'zida tabiiy mavjud noyob qiymat (masalan, email, passport_number). Surrogate key — biznes ma'nosiga ega bo'lmagan, tizim tomonidan yaratilgan sun'iy identifikator (SERIAL, UUID).

Mexanizm. Surrogate key barqaror: email o'zgarishi mumkin, lekin id hech qachon o'zgarmaydi, shuning uchun foreign key'lar buzilmaydi. Natural key esa qo'shimcha ustunni tejaydi va ba'zan ma'noli bo'ladi, lekin o'zgaruvchan yoki uzun bo'lsa index samarasizlashadi.

Kod/SQL misol:

sql

-- Surrogate: barqaror, JOIN'lar uchun qulay
CREATE TABLE users (
    id    UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email VARCHAR(255) UNIQUE NOT NULL   -- natural noyoblik alohida ta'minlanadi
);

Keng tarqalgan xato. Natural key'ni primary key qilib qo'yib, keyin u o'zgarganda barcha bog'liq jadvallarni yangilashga majbur bo'lish. Odatda surrogate key + natural key uchun UNIQUE constraint eng xavfsiz yechim.

Follow-up. SERIAL (auto-increment) va UUID primary key sifatida — masshtab va replikatsiyada qaysi biri afzal?

3-bo'lim. JOIN turlari

S: INNER JOIN nima va u qanday ishlaydi? (Junior)

Ta'rif. INNER JOIN ikki jadvalni birlashtiradi va faqat shart (ON) ikkala tomonda ham mos kelgan qatorlarni qaytaradi.

Mexanizm. Baza chap jadvalning har bir qatorini o'ng jadval qatorlari bilan ON sharti bo'yicha solishtiradi; mos kelmaydigan qatorlar natijaga tushmaydi. Ichkarida baza optimizatorga qarab nested loop, hash join yoki merge join algoritmini tanlaydi.

Kod/SQL misol:

sql

-- Faqat buyurtmasi bor foydalanuvchilar
SELECT u.name, o.amount
FROM users u
INNER JOIN orders o ON o.user_id = u.id;

Keng tarqalgan xato. INNER JOIN ishlatib, keyin "nega ba'zi foydalanuvchilar ko'rinmayapti?" deb hayron bo'lish. Buyurtmasi yo'q foydalanuvchilar tushib qoladi — bunda LEFT JOIN kerak.

Follow-up. JOIN (kalit so'z) bilan INNER JOIN bir xilmi? (Ha, INNER ixtiyoriy — yolg'iz JOIN inner join demakdir.)

S: LEFT JOIN, RIGHT JOIN va FULL OUTER JOIN farqini misol bilan tushuntiring. (Middle)

Ta'rif.

LEFT JOIN — chap jadvalning barcha qatorlari + o'ngdan mos kelganlari; mos kelmasa o'ng ustunlar NULL.
RIGHT JOIN — o'ng jadvalning barcha qatorlari + chapdan mos kelganlari.
FULL OUTER JOIN — ikkala jadvalning barcha qatorlari; mos kelmaganlarida bo'sh tomon NULL.

Mexanizm. "Outer" join'lar mos kelmagan qatorlarni ham saqlab qoladi va yo'q tomonni NULL bilan to'ldiradi. RIGHT JOIN amalda kam ishlatiladi — jadvallar tartibini almashtirib, ko'pincha LEFT JOIN bilan ifodalanadi (o'qish osonroq).

Kod/SQL misol:

sql

-- Barcha foydalanuvchilar, buyurtmasi bo'lmasa ham
SELECT u.name, o.amount
FROM users u
LEFT JOIN orders o ON o.user_id = u.id;
-- buyurtmasiz user uchun o.amount = NULL

-- Buyurtmasi umuman yo'q foydalanuvchilarni topish
SELECT u.name
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.id IS NULL;                 -- "anti-join" naqshi

Keng tarqalgan xato. LEFT JOIN yozib, keyin WHERE o.status = 'paid' qo'shish. Bu WHERE NULL qatorlarni chiqarib tashlaydi va LEFT JOINni jimgina INNER JOINga aylantiradi. To'g'ri yechim — shartni ON ichiga qo'yish: LEFT JOIN orders o ON o.user_id = u.id AND o.status = 'paid'.

Follow-up. MySQL'da FULL OUTER JOIN yo'q — uni qanday taqlid qilasiz? (LEFT JOIN UNION RIGHT JOIN.)

S: CROSS JOIN va SELF JOIN nima? Amaliy misol keltiring. (Middle)

Ta'rif. CROSS JOIN — ikki jadvalning Dekart ko'paytmasi (har bir chap qator har bir o'ng qator bilan). SELF JOIN — jadvalni o'zi bilan birlashtirish (ierarxiya yoki juftliklar uchun).

Mexanizm. CROSS JOIN N × M qator hosil qiladi — ON sharti yo'q. SELF JOINda jadvalga ikki xil alias beriladi, shunda u ikki alohida jadval kabi ishlaydi; bu xodim–menejer kabi bir jadval ichidagi bog'lanishlarni ochish uchun kerak.

Kod/SQL misol:

sql

-- CROSS JOIN: har bir o'lcham × har bir rang
SELECT s.size, c.color
FROM sizes s
CROSS JOIN colors c;

-- SELF JOIN: xodim va uning menejeri
SELECT e.name AS xodim, m.name AS menejer
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.id;

Keng tarqalgan xato. ON shartini unutib, tasodifan Dekart ko'paytmani hosil qilish (SELECT ... FROM a, b da vergul bilan). Katta jadvallarda bu millionlab qator va sekinlashuvga olib keladi.

Follow-up. SELF JOIN o'rniga rekursiv CTE qachon yaxshiroq? (Ko'p bosqichli ierarxiyada — masalan butun tashkilot daraxti.)

4-bo'lim. Normalizatsiya

S: Normalizatsiya nima va nega kerak? (Middle)

Ta'rif. Normalizatsiya — ma'lumotni takrorlanishni kamaytirish va yaxlitlikni ta'minlash maqsadida jadvallarga bo'lib chiqish jarayoni. U bir necha "normal shakl" (normal form) qoidalariga bo'ysunadi.

Mexanizm. Har bir fakt bazada faqat bir marta saqlanadi. Bu update anomaliyalarini yo'qotadi: mijoz manzilini bir joyda o'zgartirsangiz, u hamma joyda yangilanadi. Buning evaziga o'qishda ko'proq JOIN kerak bo'ladi.

Kod/SQL misol:

sql

-- Normalizatsiyaga QADAR (takror, anomaliya xavfi):
-- orders(id, customer_name, customer_city, product, price)

-- Normalizatsiyadan KEYIN:
customers(id, name, city)
products(id, name, price)
orders(id, customer_id, product_id, quantity)

Keng tarqalgan xato. Har doim maksimal normalizatsiyaga intilish. Ba'zi hollarda (analitika, hisobot) ataylab denormalizatsiya tezlik uchun to'g'ri qaror bo'ladi.

Follow-up. Update anomaliyasi, insertion anomaliyasi va deletion anomaliyasi — har biriga misol ayting.

S: 1NF, 2NF, 3NF va BCNF o'rtasidagi farqni tushuntiring. (Senior)

Ta'rif.

1NF — har bir katakda atomik (bo'linmas) qiymat; takrorlanuvchi guruh yo'q.
2NF — 1NF + har bir nokalit ustun butun primary key'ga bog'liq (qisman bog'liqlik yo'q; faqat composite kalitda dolzarb).
3NF — 2NF + nokalit ustunlar o'zaro bog'liq emas (tranzitiv bog'liqlik yo'q).
BCNF — 3NF'ning kuchliroq shakli: har bir determinant candidate key bo'lishi shart.

Mexanizm. Har bir shakl bir turdagi anomaliyani yo'qotadi. 1NF ustundagi ro'yxatlarni (masalan "tel1, tel2") alohida qatorlarga ajratadi. 2NF composite kalitning bir qismiga bog'liq ustunni ajratadi. 3NF zip city kabi tranzitiv bog'liqlikni alohida jadvalga chiqaradi. BCNF esa 3NF qamramaydigan nodir holatlarni (bir necha ustun bir-birini aniqlaydigan) qamrab oladi.

Kod/SQL misol:

sql

-- 1NF buzilgan: bitta katakda ko'p qiymat
-- students(id, name, phones = "99890..., 99891...")

-- 1NF: atomik
student_phones(student_id, phone);

-- 3NF buzilgan: zip  city tranzitiv bog'liqlik
-- orders(id, zip, city)   -- city zip'ga bog'liq, id'ga emas

-- 3NF: ajratamiz
zip_codes(zip, city);
orders(id, zip);

Keng tarqalgan xato. 2NF va 3NF'ni chalkashtirish. 2NF — nokalit ustunning kalitning bir qismiga bog'liqligi (qisman); 3NF — nokalit ustunning boshqa nokalit ustunga bog'liqligi (tranzitiv).

Follow-up. Amalda ko'p tizimlar 3NF'da to'xtaydi. Nega BCNF'ga o'tish har doim ham foydali emas?

S: Denormalizatsiya nima va qachon o'rinli? (Middle)

Ta'rif. Denormalizatsiya — o'qish tezligini oshirish uchun ataylab ma'lumotni takrorlash yoki jadvallarni birlashtirish. Bu normalizatsiyaning teskarisi.

Mexanizm. Ko'p JOIN qimmatga tushadi. Agar bir ma'lumot juda tez-tez o'qilsa (masalan, blogda maqola yonida muallif ismi), uni maqola jadvaliga nusxalab qo'yish JOINni yo'qotadi. Evaziga: yozuvda ma'lumotni bir necha joyda yangilash kerak, yaxlitlik xavfi ortadi.

Kod/SQL misol:

sql

-- Denormalizatsiya: hisoblangan qiymatni saqlab qo'yish
ALTER TABLE posts ADD COLUMN comment_count INT DEFAULT 0;

-- Har izoh qo'shilganda trigger yoki app kodi yangilaydi
UPDATE posts SET comment_count = comment_count + 1 WHERE id = 42;
-- endi COUNT(*) qilib har safar sanash shart emas

Keng tarqalgan xato. Denormalizatsiya qilib, keyin takrorlangan ma'lumotni sinxron saqlash mexanizmini (trigger yoki tranzaksiya) qo'ymaslik — natijada ma'lumotlar bir-biriga zid bo'lib qoladi.

Follow-up. Materialized view denormalizatsiyaning bir turi hisoblanadimi? Uni qachon ishlatasiz?

5-bo'lim. Index

S: Index nima va u qanday tezlashtiradi? (Junior)

Ta'rif. Index — jadval ustuni(lari) uchun tuzilgan maxsus qidiruv tuzilmasi; u qatorlarni tez topishga yordam beradi, xuddi kitob oxiridagi alifboli ko'rsatkich kabi.

Mexanizm. Indexsiz baza qatorlarni topish uchun butun jadvalni ketma-ket o'qiydi (full table scan, O(n)). Index (ko'pincha B-tree) tartiblangan tuzilma bo'lgani uchun baza qidiruvni O(log n)da bajaradi. Index alohida saqlanadi va qator o'rniga (yoki uning ko'rsatkichiga) ishora qiladi.

Kod/SQL misol:

sql

-- email bo'yicha tez qidiruv uchun index
CREATE INDEX idx_users_email ON users(email);

-- endi bu so'rov indexdan foydalanadi
SELECT * FROM users WHERE email = 'ali@example.com';

Keng tarqalgan xato. Har bir ustunga index qo'yish. Har bir index disk joyi egallaydi va INSERT/UPDATE/DELETEni sekinlashtiradi, chunki har yozuvda index ham yangilanishi kerak.

Follow-up. Index qo'yilgan, lekin so'rov baribir sekin. Sabablari qanday bo'lishi mumkin?

S: B-tree index ichkarida qanday ishlaydi? (Senior)

Ta'rif. B-tree (balanced tree) — muvozanatlangan, ko'p tarmoqli qidiruv daraxti; aksariyat relational bazalarda standart index turi.

Mexanizm. Har bir tugun (node) tartiblangan kalitlar va bolalarga ko'rsatkichlarni saqlaydi. Daraxt muvozanatlangan — barcha barg (leaf) tugunlari bir xil chuqurlikda, shuning uchun har qanday qidiruv bir xil qadam sonini talab qiladi. Barg tugunlari o'zaro bog'langan (linked list), bu diapazon (range, BETWEEN, >, <) va tartiblangan (ORDER BY) so'rovlarni tez qiladi. Har bir tugun disk sahifasiga (page) mos kelgani uchun disk o'qishlari minimallashadi.

Kod/SQL misol:

sql

-- B-tree diapazon va tartib so'rovlarida ustun:
CREATE INDEX idx_orders_date ON orders(created_at);

SELECT * FROM orders
WHERE created_at BETWEEN '2026-01-01' AND '2026-03-31'
ORDER BY created_at;          -- index tartibidan foydalanadi

Keng tarqalgan xato. B-tree'ni tenglik (=) uchun eng yaxshi deb bilish. Aniq tenglik va noyob qidiruvda hash index ba'zan tezroq, lekin u diapazon va tartibni qo'llab-quvvatlamaydi — shu sabab B-tree ko'p maqsadli standart.

Follow-up. Baza LIKE 'abc%' uchun indexdan foydalanadi, lekin LIKE '%abc' uchun foydalanmaydi. Nega?

S: Composite index va covering index nima? Ustunlar tartibi nega muhim? (Senior)

Ta'rif. Composite index — bir necha ustun bo'yicha yagona index. Covering index — so'rovga kerakli barcha ustunlarni o'z ichiga olgan index, shu sababdan baza jadval qatoriga umuman murojaat qilmaydi.

Mexanizm. Composite index leftmost prefix qoidasiga bo'ysunadi: (a, b, c) indexi a, (a, b), (a, b, c) bo'yicha qidiruvda ishlaydi, lekin faqat b yoki c bo'yicha ishlamaydi. Covering index'da baza kerakli ma'lumotni to'g'ridan-to'g'ri indexdan oladi (index-only scan) — jadvalga "sakrash" (heap fetch) yo'q, shuning uchun juda tez.

Kod/SQL misol:

sql

-- Composite index
CREATE INDEX idx_orders_user_status ON orders(user_id, status);

-- Ishlaydi: user_id bosh ustun
SELECT * FROM orders WHERE user_id = 5 AND status = 'paid';
-- Ishlaydi: faqat leftmost ustun
SELECT * FROM orders WHERE user_id = 5;
-- ISHLAMAYDI (yolg'iz status): leftmost prefix buzildi
SELECT * FROM orders WHERE status = 'paid';

-- Covering index: SELECT ustunlari ham indexda (INCLUDE)
CREATE INDEX idx_cover ON orders(user_id) INCLUDE (status, amount);

Keng tarqalgan xato. Composite indexda past selektivlikli (kam qiymatli, masalan status) ustunni birinchi qo'yish. Odatda selektivligi yuqori (ko'p noyob qiymatli) ustunni oldinga qo'yish yaxshiroq — index tezroq toraytiradi.

Follow-up. Sizda (a, b) va (b, a) indexlari bor. Ular ekvivalentmi? Ikkalasini ham saqlash mantiqiymi?

6-bo'lim. So'rov optimizatsiyasi

S: EXPLAIN nima uchun ishlatiladi va undan nimani o'qiysiz? (Middle)

Ta'rif. EXPLAIN — bazaning so'rovni qanday bajarishni rejalashtirganini (query plan) ko'rsatadigan buyruq. EXPLAIN ANALYZE esa so'rovni haqiqatan bajarib, real vaqt va qator sonini qaytaradi.

Mexanizm. Rejadan siz ko'rasiz: qaysi index ishlatildi (yoki Seq Scan — full table scan), join turi (Nested Loop / Hash / Merge), taxminiy va real qator soni, xarajat (cost). Seq Scan katta jadvalda ko'rinsa — bu ehtimol yo'qolgan index belgisi. Taxminiy va real qator soni juda farq qilsa — statistika eskirgan (ANALYZE kerak).

Kod/SQL misol:

sql

EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 5;

-- Yaxshi natija:
--   Index Scan using idx_orders_user_id ...
-- Yomon natija (index yo'q):
--   Seq Scan on orders  (rows=1000000 ...)

Keng tarqalgan xato. Kichik test bazasida EXPLAIN qilib, "index kerak emas" deb xulosa chiqarish. Kam ma'lumotda baza seq scan'ni tezroq deb tanlashi mumkin; index foydasi faqat katta hajmda ko'rinadi.

Follow-up. Rejadagi "cost" birligini qanday o'qiysiz — u millisekundmi?

S: N+1 query muammosi nima? Uni qanday aniqlab, qanday hal qilasiz? (Senior)

Ta'rif. N+1 — bir so'rov (1) bilan N ta yozuv olib, keyin har biri uchun alohida qo'shimcha so'rov (N ta) yuborilishi. Natijada 1 + N ta so'rov ketadi. Bu odatda ORM lazy loading tufayli yuzaga keladi.

Mexanizm. Masalan, 100 ta post olasiz (1 so'rov), keyin har postning muallifini ko'rsatish uchun sikl ichida SELECT * FROM users WHERE id = ? (100 so'rov). Ma'lumot bazasi bilan 101 marta aloqa qilinadi — har biri tarmoq kechikishi (round-trip) qo'shadi. Yechim: kerakli ma'lumotni bitta JOINda yoki IN (...) bilan partiyalab (eager loading) olish.

Kod/SQL misol:

javascript

//  N+1: har post uchun alohida so'rov
const posts = await db.query('SELECT * FROM posts');
for (const post of posts) {
  post.author = await db.query(
    'SELECT * FROM users WHERE id = $1', [post.user_id]);  // N ta so'rov!
}

sql

--  Yechim 1: bitta JOIN
SELECT p.*, u.name AS author
FROM posts p
JOIN users u ON u.id = p.user_id;

--  Yechim 2: partiyali IN (ORM'da eager load / include)
SELECT * FROM users WHERE id IN (1, 2, 3, ...);

Keng tarqalgan xato. N+1'ni faqat "sekin sahifa" deb sezish, lekin ildizini aniqlamaslik. Uni so'rov loglari yoki APM (masalan bir sahifada 200+ so'rov ko'rinsa) orqali aniqlash kerak; ORM'da include/join/prefetch sozlanmagan bo'ladi.

Follow-up. Eager loading har doim yaxshiroqmi? Qachon u ortiqcha ma'lumot yuklab, aksincha zarar keltiradi?

S: SELECT * nega yomon amaliyot va qachon maqbul? (Middle)

Ta'rif. SELECT * — jadvaldagi barcha ustunlarni qaytaradi. Ishlab chiqarish kodida odatda faqat kerakli ustunlarni tanlash tavsiya etiladi.

Mexanizm. SELECT * kerak bo'lmagan ustunlarni ham disk va tarmoq orqali uzatadi (masalan katta TEXT/BLOB). Bundan tashqari, u covering indexdan foydalanish imkonini yo'qotadi — baza jadval qatoriga murojaat qilishga majbur. Sxema o'zgarsa (ustun qo'shilsa), SELECT * kutilmagan xatti-harakat berishi mumkin.

Kod/SQL misol:

sql

--  Ortiqcha ustunlar, covering indexdan foydalana olmaydi
SELECT * FROM users WHERE status = 'active';

--  Faqat kerakli ustunlar
SELECT id, name FROM users WHERE status = 'active';

Keng tarqalgan xato. SELECT *ni ORM ortida yashiringan deb bilib e'tibor bermaslik — ko'p ORM'lar sukut bo'yicha barcha ustunlarni oladi, bu esa katta jadvallarda sezilarli yukdir.

Follow-up. SELECT COUNT(*) ham "hamma ustun" degan ma'noni bildiradimi? (Yo'q — COUNT(*) faqat qatorlarni sanaydi, ustunlarni o'qimaydi.)

7-bo'lim. ACID va tranzaksiyalar

S: Tranzaksiya (transaction) nima? (Junior)

Ta'rif. Tranzaksiya — bir yoki bir necha SQL amalining yagona, bo'linmas birlik sifatida bajarilishi. Ular yo to'liq muvaffaqiyatli (COMMIT), yo to'liq bekor (ROLLBACK) bo'ladi.

Mexanizm. Tranzaksiya BEGIN bilan boshlanadi. Ichidagi barcha o'zgarishlar COMMITgacha "vaqtinchalik". Agar oraliqda xato bo'lsa, ROLLBACK hamma o'zgarishni orqaga qaytaradi — baza tranzaksiya boshlanishidan oldingi holatga qaytadi. Klassik misol: pul o'tkazmasi — bir hisobdan yechish va boshqasiga qo'shish birga bajarilishi shart.

Kod/SQL misol:

sql

BEGIN;
    UPDATE accounts SET balance = balance - 100 WHERE id = 1;
    UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;   -- ikkalasi ham saqlanadi; xato bo'lsa ROLLBACK

Keng tarqalgan xato. Ko'p bosqichli biznes amalini tranzaksiyaga o'ramaslik — birinchi UPDATE o'tib, ikkinchisi xato bersa, pul "yo'qoladi".

Follow-up. SAVEPOINT nima va u tranzaksiya ichida qanday yordam beradi?

S: ACID — har bir harfni tushuntiring. (Senior)

Ta'rif. ACID — ishonchli tranzaksiyaning to'rt kafolati: Atomicity, Consistency, Isolation, Durability.

Mexanizm.

Atomicity (atomiklik) — tranzaksiya bo'linmas: hammasi bajariladi yoki hech biri. Xato bo'lsa ROLLBACK.
Consistency (izchillik) — tranzaksiya bazani bir yaroqli holatdan ikkinchi yaroqli holatga o'tkazadi; barcha constraint (FK, CHECK, UNIQUE) saqlanadi.
Isolation (izolyatsiya) — bir vaqtda ishlayotgan tranzaksiyalar bir-biriga xalaqit bermaydi; natija ular ketma-ket bajarilgandek bo'ladi.
Durability (bardoshlilik) — COMMITdan keyin ma'lumot doimiy saqlanadi, hatto tizim o'chib qolsa ham (write-ahead log / WAL orqali).

Kod/SQL misol:

sql

BEGIN;
    -- Atomicity: ikkisi ham yoki hech biri
    UPDATE accounts SET balance = balance - 100 WHERE id = 1;
    UPDATE accounts SET balance = balance + 100 WHERE id = 2;
    -- Consistency: CHECK (balance >= 0) buzilsa, ROLLBACK
COMMIT;
    -- Durability: COMMITdan keyin disk quvvat o'chsa ham saqlanadi

Keng tarqalgan xato. Consistency'ni Isolation bilan chalkashtirish. Consistency — qoidalar (constraint) buzilmasligi; Isolation — parallel tranzaksiyalarning bir-biriga ko'rinmasligi.

Follow-up. Durability qanday ta'minlanadi? Write-Ahead Log (WAL) rolini tushuntiring.

S: Isolation level'lar va ular oldini oladigan anomaliyalarni tushuntiring. (Senior)

Ta'rif. Isolation level — parallel tranzaksiyalarning bir-birini qanchalik "ko'rishi"ni belgilaydigan daraja. SQL standarti to'rtta darajani belgilaydi: Read Uncommitted, Read Committed, Repeatable Read, Serializable.

Mexanizm. Har bir daraja ma'lum anomaliyalarni oldini oladi (past darajadan yuqoriga):

Dirty read — boshqa tranzaksiyaning hali COMMIT qilinmagan (keyin bekor bo'lishi mumkin) ma'lumotini o'qish.
Non-repeatable read — bir tranzaksiyada bir qatorni ikki marta o'qiganda, oraliqda boshqa tranzaksiya uni o'zgartirgani sabab, turli qiymat olish.
Phantom read — bir shart bo'yicha o'qilgan qatorlar to'plami ikkinchi o'qishda o'zgarishi (yangi qatorlar "paydo bo'lishi").

Isolation level	Dirty read	Non-repeatable	Phantom
Read Uncommitted	mumkin	mumkin	mumkin
Read Committed	yo'q	mumkin	mumkin
Repeatable Read	yo'q	yo'q	mumkin*
Serializable	yo'q	yo'q	yo'q

*PostgreSQL'da Repeatable Read (snapshot) phantom'ni ham oldini oladi.

Kod/SQL misol:

sql

-- Tranzaksiya uchun izolyatsiya darajasini o'rnatish
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
    SELECT SUM(amount) FROM orders WHERE user_id = 5;
    -- Serializable'da bu snapshot barqaror qoladi
COMMIT;

Keng tarqalgan xato. "Serializable eng yaxshisi — doim ishlataman" deb o'ylash. U eng xavfsiz, lekin eng qimmat: ko'proq lock/qayta urinish (serialization failure) va past throughput. Ko'p tizimlar uchun Read Committed (aksariyat bazalarning default'i) yetarli.

Follow-up. Optimistic va pessimistic concurrency control farqi nima va qay biri qaysi izolyatsiyaga mos keladi?

S: Deadlock nima, nega yuzaga keladi va qanday oldini olasiz? (Senior)

Ta'rif. Deadlock — ikki (yoki undan ko'p) tranzaksiya bir-biri ushlab turgan resursni (lock) kutib, ikkalasi ham davom eta olmay qolgan holat.

Mexanizm. Tranzaksiya A row1ni lock qiladi va row2ni kutadi; ayni vaqtda tranzaksiya B row2ni lock qilib, row1ni kutadi — halqa (cycle) hosil bo'ladi. Baza deadlock detektori buni aniqlab, tranzaksiyalardan birini "qurbon" (victim) sifatida bekor qiladi (ROLLBACK), ikkinchisi davom etadi. Oldini olishning asosiy usuli — barcha tranzaksiyalarda resurslarni bir xil tartibda lock qilish.

Kod/SQL misol:

sql

-- Deadlock keltiradigan naqsh (teskari tartib):
-- Tranzaksiya A:              -- Tranzaksiya B:
UPDATE accounts ... id = 1;    UPDATE accounts ... id = 2;
UPDATE accounts ... id = 2;    UPDATE accounts ... id = 1;  -- deadlock!

-- Yechim: doim id bo'yicha o'sish tartibida lock qiling
--   (ikkala tranzaksiya ham avval id=1, keyin id=2)

Keng tarqalgan xato. Deadlock'ni umuman oldini olish mumkin deb o'ylash. Yuqori yuklamada u vaqti-vaqti bilan bo'lishi tabiiy — kod deadlock (masalan PostgreSQL 40P01) xatosini ushlab, tranzaksiyani qayta urinadigan (retry) qilib yozilishi kerak.

Follow-up. Row-level lock va table-level lock farqi nima? Qaysi biri deadlock ehtimolini oshiradi?

8-bo'lim. Aggregatsiya va guruhlash

S: GROUP BY va HAVING farqi nima? (Junior)

Ta'rif. GROUP BY qatorlarni bir yoki bir necha ustun bo'yicha guruhlarga birlashtiradi. HAVING — guruhlarni agregat shart bo'yicha filtrlaydi (WHERE guruhlashdan oldin, HAVING keyin ishlaydi).

Mexanizm. Bajarilish tartibi: FROM WHERE (alohida qatorlar) GROUP BY (guruhlash) HAVING (guruhlar) SELECT ORDER BY. Shuning uchun WHEREda agregat (COUNT, SUM) ishlata olmaysiz — guruh hali tuzilmagan; agregat shart faqat HAVINGda yoziladi.

Kod/SQL misol:

sql

-- 5 tadan ortiq buyurtma bergan foydalanuvchilar
SELECT user_id, COUNT(*) AS order_count
FROM orders
WHERE status = 'paid'          -- guruhlashdan OLDIN qatorlarni filtr
GROUP BY user_id
HAVING COUNT(*) > 5            -- guruhlashdan KEYIN guruhlarni filtr
ORDER BY order_count DESC;

Keng tarqalgan xato. WHERE COUNT(*) > 5 yozish — bu xato beradi. Agregat shart HAVINGda bo'lishi kerak.

Follow-up. SELECTda GROUP BYga kiritilmagan, lekin agregat ham bo'lmagan ustunni tanlasangiz nima bo'ladi? (Standart SQL'da xato; MySQL eski rejimda kutilmagan qiymat qaytaradi.)

S: Aggregate funksiyalar NULL qiymatlarni qanday ishlaydi? (Middle)

Ta'rif. Aggregate funksiyalar (COUNT, SUM, AVG, MIN, MAX) NULL qiymatlarni e'tiborsiz qoldiradi — bitta muhim istisno: COUNT(*).

Mexanizm. COUNT(*) barcha qatorlarni (jumladan NULLli) sanaydi. COUNT(column) esa faqat NULL bo'lmagan qatorlarni sanaydi. AVG(column) NULLlarni hisobga olmaydi — ular 0 sifatida qaralmaydi, balki bo'linuvchi sonidan chiqarib tashlanadi. Bu tafovut o'rtacha qiymatga jiddiy ta'sir qiladi.

Kod/SQL misol:

sql

-- salary ustunida ba'zi NULL qiymatlar bor deylik
SELECT
    COUNT(*)         AS all_rows,      -- barcha qatorlar
    COUNT(salary)    AS non_null_rows, -- faqat NULL bo'lmaganlar
    AVG(salary)      AS avg_salary,    -- NULLlar hisobga olinmaydi
    AVG(COALESCE(salary, 0)) AS avg_with_zero  -- NULLni 0 deb sanash
FROM employees;

Keng tarqalgan xato. AVG(salary) NULLlarni 0 deb hisoblaydi deb o'ylash. Agar ularni 0 sifatida sanamoqchi bo'lsangiz, COALESCE/IFNULL bilan aniq belgilash kerak.

Follow-up. SUM bo'sh natija to'plamiga (0 qator) qo'llanilsa nima qaytaradi — 0 mi yoki NULLmi?

9-bo'lim. Subquery, CTE va window funksiyalar

S: Subquery va JOIN — qay birini qachon tanlaysiz? (Middle)

Ta'rif. Subquery — boshqa so'rov ichidagi so'rov. JOIN — jadvallarni ustun bo'yicha birlashtirish. Ko'p hollarda bir masalani ikkalasi bilan ham yechish mumkin.

Mexanizm. JOIN odatda bir necha jadvaldan ustunlarni birga ko'rsatish kerak bo'lganda tabiiy va tez. Subquery esa mavjudlik tekshiruvi (EXISTS), agregat bilan taqqoslash yoki bosqichma-bosqich mantiq uchun o'qilishi osonroq. Zamonaviy optimizatorlar ikkalasini ko'pincha bir xil rejaga aylantiradi, lekin korrelyatsiyalangan (correlated) subquery har tashqi qator uchun qayta bajarilib, sekin bo'lishi mumkin.

Kod/SQL misol:

sql

-- JOIN bilan
SELECT DISTINCT u.name
FROM users u
JOIN orders o ON o.user_id = u.id;

-- EXISTS subquery bilan (ko'pincha tezroq: birinchi mos qatorda to'xtaydi)
SELECT u.name
FROM users u
WHERE EXISTS (
    SELECT 1 FROM orders o WHERE o.user_id = u.id
);

Keng tarqalgan xato. "Buyurtmasi bor userlar" uchun JOIN + DISTINCT ishlatish — agar bir userda 100 buyurtma bo'lsa, JOIN 100 qator hosil qilib, keyin DISTINCT ularni siqadi (ortiqcha ish). EXISTS bu holatda samaraliroq.

Follow-up. IN (subquery) va EXISTS (subquery) farqi nima, ayniqsa subquery NULL qaytarganda?

S: Window funksiya nima? U GROUP BY'dan qanday farq qiladi? (Senior)

Ta'rif. Window funksiya — qatorlar oynasi (window) bo'yicha hisoblab, natijada har bir qatorni saqlab qoladigan funksiya (ROW_NUMBER, RANK, LAG, LEAD, SUM() OVER (...)).

Mexanizm. GROUP BY qatorlarni bitta guruhga siqadi (N qator 1 qator). Window funksiya esa OVER (...) bilan ishlaydi va qatorlar sonini saqlaydi — har qatorga guruh bo'yicha hisoblangan qiymatni qo'shadi. PARTITION BY guruhni belgilaydi, ORDER BY oyna ichidagi tartibni. Bu running total, reyting, oldingi/keyingi qator bilan taqqoslash uchun ajralmas vosita.

Kod/SQL misol:

sql

-- Har bo'lim ichida maoshlar reytingi (qatorlar saqlanadi)
SELECT
    name,
    department,
    salary,
    RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS dept_rank,
    SUM(salary) OVER (PARTITION BY department) AS dept_total
FROM employees;

Keng tarqalgan xato. Window funksiyani WHEREda ishlatishga urinish (WHERE ROW_NUMBER() OVER (...) = 1). Window funksiya SELECT/ORDER BY bosqichida hisoblanadi, WHEREdan keyin — shuning uchun uni subquery yoki CTE ichiga o'rab, tashqarida filtrlash kerak.

Follow-up. ROW_NUMBER, RANK va DENSE_RANK orasidagi farq nima, teng qiymatlar bo'lganda?

S: CTE (Common Table Expression) nima va qachon foydali? (Middle)

Ta'rif. CTE — WITH kalit so'zi bilan e'lon qilinadigan, so'rov davomida ishlatiladigan nomlangan vaqtinchalik natija to'plami.

Mexanizm. CTE murakkab so'rovni bosqichlarga bo'lib, o'qishni osonlashtiradi — subquery'larni ichma-ich yozish o'rniga ketma-ket, nom bilan tuzasiz. Rekursiv CTE (WITH RECURSIVE) ierarxik ma'lumot (kategoriyalar daraxti, tashkilot tuzilmasi) bo'yicha yurishga imkon beradi. CTE bir so'rov doirasida yashaydi va tashqarida ko'rinmaydi.

Kod/SQL misol:

sql

-- Oddiy CTE: o'qish oson bosqichlar
WITH high_earners AS (
    SELECT * FROM employees WHERE salary > 5000
)
SELECT department, COUNT(*) FROM high_earners GROUP BY department;

-- Rekursiv CTE: kategoriyalar daraxti
WITH RECURSIVE tree AS (
    SELECT id, name, parent_id FROM categories WHERE parent_id IS NULL
    UNION ALL
    SELECT c.id, c.name, c.parent_id
    FROM categories c JOIN tree t ON c.parent_id = t.id
)
SELECT * FROM tree;

Keng tarqalgan xato. CTE har doim optimallashadi deb o'ylash. Ba'zi bazalarda (eski PostgreSQL 11 va oldingi) CTE "optimization fence" bo'lib, alohida materializatsiya qilinadi va so'rovni sekinlashtiradi. Bunday hollarda subquery tezroq bo'lishi mumkin.

Follow-up. Rekursiv CTE cheksiz siklga tushib qolmasligi uchun qanday himoya qo'yasiz?

S: View va materialized view farqi nima? (Middle)

Ta'rif. View — saqlangan so'rov ustidagi virtual jadval; har murojaatda asosiy so'rov qayta bajariladi. Materialized view — so'rov natijasini jismonan diskda saqlaydi va vaqti-vaqti bilan yangilanadi.

Mexanizm. View ma'lumot saqlamaydi — u faqat so'rovga qulay nom. Materialized view esa natijani "muzlatib" saqlaydi, shuning uchun o'qish tez, lekin ma'lumot eskirgan (stale) bo'lishi mumkin; REFRESH MATERIALIZED VIEW bilan yangilanadi. Materialized view — og'ir agregatsiyani (hisobotlar, dashboard) oldindan hisoblab qo'yish uchun ideal.

Kod/SQL misol:

sql

-- Oddiy view: har safar qayta hisoblanadi (doim yangi)
CREATE VIEW active_users AS
    SELECT * FROM users WHERE status = 'active';

-- Materialized view: natija saqlanadi (tez, lekin eskiradi)
CREATE MATERIALIZED VIEW monthly_sales AS
    SELECT date_trunc('month', created_at) AS month, SUM(amount) AS total
    FROM orders GROUP BY 1;

REFRESH MATERIALIZED VIEW monthly_sales;  -- yangilash

Keng tarqalgan xato. Materialized view'ni "avtomatik yangilanadi" deb o'ylash. Ko'p bazalarda uni qo'lda yoki rejalashtirilgan (cron/trigger) tarzda yangilash kerak, aks holda ma'lumot eskiradi.

Follow-up. REFRESH MATERIALIZED VIEW CONCURRENTLY oddiy REFRESHdan nimasi bilan farq qiladi?

10-bo'lim. Stored procedure, trigger va view

S: Stored procedure nima va uning afzallik/kamchiliklari? (Middle)

Ta'rif. Stored procedure — bazada saqlangan, nomlangan va chaqirib ishlatiladigan SQL kod bloki (mantiq, sikl, shart bilan).

Mexanizm. Kod bazaning o'zida ishlaydi — bu tarmoq aylanishlarini (round-trip) kamaytiradi, chunki ko'p amal bir chaqiruvda bajariladi. Baza uni oldindan kompilyatsiya qilishi mumkin (tezroq). Kamchiligi: biznes mantiq bazaga "yashiringan" bo'lib, versiya nazorati, test va debug qiyinlashadi; bazadan bazaga ko'chirish og'ir.

Kod/SQL misol:

sql

CREATE PROCEDURE transfer(
    IN from_id INT, IN to_id INT, IN sum NUMERIC
)
LANGUAGE plpgsql AS $$
BEGIN
    UPDATE accounts SET balance = balance - sum WHERE id = from_id;
    UPDATE accounts SET balance = balance + sum WHERE id = to_id;
END;
$$;

CALL transfer(1, 2, 100);

Keng tarqalgan xato. Barcha biznes mantiqni stored procedure'ga ko'chirish. Bu bazani "shishirib", mikroservis arxitekturasida masshtablashni qiyinlashtiradi — mantiqni ko'pincha ilova (application) qatlamida saqlash moslashuvchanroq.

Follow-up. Stored procedure va function (funksiya) o'rtasidagi farq nima?

S: Trigger nima va qachon ishlatiladi (hamda ehtiyot bo'lish kerak)? (Middle)

Ta'rif. Trigger — jadvalga INSERT/UPDATE/DELETE bo'lganda avtomatik ishga tushadigan maxsus procedure.

Mexanizm. Trigger hodisa (event) va vaqtga (BEFORE/AFTER) bog'lanadi. U audit log yozish, hosila (derived) ustunni yangilash yoki qoidani majburlash uchun ishlatiladi. Kuchli, lekin "yashirin": ma'lumot o'zgarishida siz kutmagan qo'shimcha amallar sodir bo'ladi, shuning uchun debug qiyin va yaxshi hujjatlanmasa xatolarga olib keladi.

Kod/SQL misol:

sql

-- Har yangilashda updated_at ni avtomatik yangilash
CREATE OR REPLACE FUNCTION set_updated_at()
RETURNS TRIGGER AS $$
BEGIN
    NEW.updated_at = NOW();
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_updated_at
BEFORE UPDATE ON users
FOR EACH ROW EXECUTE FUNCTION set_updated_at();

Keng tarqalgan xato. Triggerlarni zanjir qilib qo'yish (bir trigger boshqa jadvalni o'zgartirib, u yana trigger ishga tushiradi) — natijada ko'rinmas rekursiya va ish unumdorligi tushishi. Og'ir mantiqni triggerda emas, ilova qatlamida saqlash xavfsizroq.

Follow-up. BEFORE va AFTER trigger o'rtasidagi farq nima va qay birida NEW qatorni o'zgartira olasiz?

11-bo'lim. Taqsimlangan bazalar (distributed)

S: CAP teoremasi nima? (Senior)

Ta'rif. CAP teoremasi — taqsimlangan tizimda uch xususiyatdan (Consistency, Availability, Partition tolerance) bir vaqtning o'zida faqat ikkitasini to'liq kafolatlash mumkinligini bildiradi.

Mexanizm.

Consistency (izchillik) — har o'qish eng so'nggi yozilgan qiymatni qaytaradi (barcha tugunlarda bir xil).
Availability (mavjudlik) — har so'rov (xato bo'lmagan) javob oladi, hatto ma'lumot eng so'nggi bo'lmasa ham.
Partition tolerance (bo'linishga bardosh) — tugunlar orasidagi tarmoq uzilsa ham tizim ishlaydi.

Tarmoq bo'linishi (partition) real tizimda muqarrar, shuning uchun Pdan voz kecha olmaysiz. Demak amalda tanlov C va A orasida: bo'linish paytida yo izchillikni saqlash uchun ba'zi so'rovlarni rad etasiz (CP), yo mavjudlikni saqlab, eskirgan ma'lumot berasiz (AP).

Kod/SQL misol:

text

CP tizim   MongoDB (default), HBase   (izchillik ustun)
AP tizim   Cassandra, DynamoDB        (mavjudlik ustun)
CA (faqat)  bitta tugunli klassik RDBMS (partition yo'q deb faraz)

Keng tarqalgan xato. "CAP'dan ikkita tanlayman" deb Pni tashlab, CA tanlash. Taqsimlangan tizimda P majburiy — real tanlov faqat CP va AP orasida.

Follow-up. PACELC teoremasi CAP'ni qanday to'ldiradi? (Bo'linish bo'lmaganda ham Latency va Consistency orasida tanlov borligini qo'shadi.)

S: Sharding nima va uni qanday amalga oshirasiz? (Senior)

Ta'rif. Sharding — katta bazani gorizontal bo'lib, ma'lumotni bir necha alohida baza serveriga (shard) taqsimlash. Har shard ma'lumotning bir qismini saqlaydi.

Mexanizm. Qaysi qator qaysi shardga tushishi shard key (masalan user_id) orqali aniqlanadi. Strategiyalar: range-based (id 1–1M shard 1), hash-based (hash(id) % N), directory-based (xarita jadvali). Sharding yozuv va o'qish yukini serverlarga tarqatadi, lekin cross-shard JOIN va tranzaksiya murakkablashadi.

Kod/SQL misol:

text

Hash sharding: shard = hash(user_id) % 4

user_id=101  hash  shard_1
user_id=102  hash  shard_3
...
Har shard mustaqil PostgreSQL instansi

Keng tarqalgan xato. Yomon shard key tanlash — bu hot shardga olib keladi (masalan country bo'yicha sharding qilsangiz, bir davlat butun yukni oladi). Shard key bir xil taqsimlanadigan (yuqori kardinallik) bo'lishi kerak.

Follow-up. Shardlar soni yetmay qolganda re-sharding qanday muammo tug'diradi? Consistent hashing bunga qanday yordam beradi?

S: Replikatsiya (master-slave) nima va nega kerak? (Middle)

Ta'rif. Replikatsiya — ma'lumotni bir nechta serverga nusxalash. Master-slave (yoki primary-replica) modelida yozuv bitta master'ga, o'qish esa bir necha replika'ga tarqatiladi.

Mexanizm. Master barcha yozuvni qabul qiladi va o'zgarishlarni (WAL/binlog orqali) replika'larga uzatadi. Replika'lar o'qish yukini ko'taradi (read scaling) va zaxira (failover) vazifasini bajaradi — master ishdan chiqsa, replika master'ga ko'tariladi. Uzatish asinxron bo'lsa, replikada replication lag (kechikish) yuzaga keladi.

Kod/SQL misol:

text

              ┌── Replica 1 (read)
Master ──WAL──┼── Replica 2 (read)
 (write)      └── Replica 3 (read, failover uchun)

Ilova: yozuvni master'ga, o'qishni replica'larga yo'naltiradi

Keng tarqalgan xato. Yozuvdan so'ng darhol replika'dan o'qish — replication lag tufayli eski ma'lumot qaytishi mumkin ("read-your-writes" muammosi). Kritik o'qishlarni master'ga yo'naltirish yoki sinxron replikatsiya kerak.

Follow-up. Sinxron va asinxron replikatsiya farqi nima? Har biri CAP'da qaysi tomonni tanlaydi?

S: Partitioning va sharding orasidagi farq nima? (Middle)

Ta'rif. Partitioning — bitta jadvalni bir baza ichida kichik bo'laklarga (partition) bo'lish. Sharding — ma'lumotni bir necha alohida serverga taqsimlash.

Mexanizm. Partitioning'da baza bitta mantiqiy jadvalni jismonan bir necha bo'lakka ajratadi (masalan sana bo'yicha oylik partition). So'rovda faqat kerakli partition o'qiladi (partition pruning) — bu katta jadvallarda tezlik beradi. Sharding esa bir necha mashina bo'ylab taqsimlaydi, shuning uchun u masshtab va yukni tarqatishni hal qiladi, lekin murakkabroq.

Kod/SQL misol:

sql

-- Range partitioning: sana bo'yicha
CREATE TABLE orders (
    id INT, created_at DATE, amount NUMERIC
) PARTITION BY RANGE (created_at);

CREATE TABLE orders_2026_q1 PARTITION OF orders
    FOR VALUES FROM ('2026-01-01') TO ('2026-04-01');

-- Bu so'rov faqat q1 partition'ni o'qiydi (pruning)
SELECT * FROM orders WHERE created_at = '2026-02-15';

Keng tarqalgan xato. Partition key'ni so'rov shartiga qo'shmaslik. Agar WHEREda partition ustuni bo'lmasa, baza barcha partitionlarni skan qiladi — pruning ishlamaydi va foyda yo'qoladi.

Follow-up. Range, list va hash partitioning qachon qay biri mos keladi?

12-bo'lim. Ulanish, ORM va xavfsizlik

S: Connection pooling nima va nega muhim? (Middle)

Ta'rif. Connection pooling — bazaga oldindan ochilgan ulanishlarni (connection) hovuzda (pool) saqlab, ularni qayta ishlatish texnikasi.

Mexanizm. Har yangi baza ulanishini ochish qimmat: TCP handshake, autentifikatsiya, resurs ajratish. Pool bir necha ulanishni oldindan ochib qo'yadi; ilova so'rov paytida hovuzdan tayyor ulanishni oladi, ishlatib, qaytaradi. Bu kechikishni kamaytiradi va bazaning ulanishlar limitidan oshib ketishining oldini oladi (har ulanish xotira oladi).

Kod/SQL misol:

javascript

// Node.js (pg) — pool
const { Pool } = require('pg');
const pool = new Pool({
  host: 'localhost', database: 'app',
  max: 20,                 // maksimal ulanishlar
  idleTimeoutMillis: 30000 // bo'sh ulanish qancha turadi
});

// so'rov pool orqali: ulanish avtomatik olinadi va qaytariladi
const res = await pool.query('SELECT * FROM users WHERE id = $1', [5]);

Keng tarqalgan xato. Serverless (Lambda) muhitida har chaqiruvda yangi pool ochish — bu tez orada bazaning max_connections limitini tugatadi. Serverless'da tashqi pooler (masalan PgBouncer) yoki bitta global pool kerak.

Follow-up. Pool max qiymatini juda katta qo'yish nega zararli bo'lishi mumkin?

S: ORM nima va uning N+1 kabi tuzoqlari qanday? (Senior)

Ta'rif. ORM (Object-Relational Mapping) — jadval qatorlarini dasturlash tili obyektlariga avtomatik bog'laydigan kutubxona (Prisma, Sequelize, Hibernate, Django ORM).

Mexanizm. ORM SQL yozishni obyekt metodlariga aylantiradi (user.orders.create(...)), migratsiya va tip xavfsizligini beradi. Lekin abstraksiya SQL'ni yashiradi: lazy loading N+1 so'rovga olib keladi, generatsiya qilingan so'rovlar ba'zan samarasiz (SELECT *, ortiqcha JOIN), murakkab agregatsiyalarda esa xom SQL kerak bo'ladi.

Kod/SQL misol:

javascript

//  Lazy loading  N+1
const users = await User.findAll();
for (const u of users) {
  const orders = await u.getOrders();   // har user uchun alohida so'rov
}

//  Eager loading (include)  1-2 so'rov
const users = await User.findAll({
  include: [{ model: Order }]           // JOIN yoki partiyali IN
});

Keng tarqalgan xato. ORM'ga to'liq ishonib, generatsiya qilingan SQL'ni hech tekshirmaslik. Ishlab chiqarish tizimida so'rov loglarini yoqib, ORM aslida qanday SQL yuborayotganini ko'rish shart.

Follow-up. Query builder (masalan Knex) va to'liq ORM o'rtasidagi farq nima? Qachon xom SQL'ga tushasiz?

S: SQL injection nima va undan qanday himoyalanasiz? (Senior)

Ta'rif. SQL injection — foydalanuvchi kiritmasini SQL so'roviga to'g'ridan-to'g'ri qo'shish natijasida hujumchi zararli SQL bajara oladigan zaiflik.

Mexanizm. Agar so'rov satr birlashtirish (concatenation) bilan tuzilsa, hujumchi kiritma orqali so'rov mantig'ini o'zgartiradi — ma'lumotni o'qishi, o'chirishi yoki autentifikatsiyani chetlab o'tishi mumkin. Asosiy himoya — parametrlangan so'rov (prepared statement): baza SQL kodini va ma'lumotni alohida qabul qiladi, shuning uchun kiritma hech qachon kod sifatida bajarilmaydi.

Kod/SQL misol:

javascript

//  ZAIF: kiritma to'g'ridan-to'g'ri so'rovga qo'shiladi
const q = `SELECT * FROM users WHERE email = '${input}'`;
// input = "' OR '1'='1"    hamma qatorni qaytaradi!

//  HIMOYALANGAN: parametrlangan so'rov
const res = await pool.query(
  'SELECT * FROM users WHERE email = $1',
  [input]                 // qiymat alohida uzatiladi, kod emas
);

Keng tarqalgan xato. Faqat kiritmani "tozalash" (escape/filter) bilan cheklanish. Bu ishonchsiz — har bir chekka holatni qamramaydi. To'g'ri yechim doim parametrlangan so'rov yoki ORM'ning bog'langan (bound) parametrlari.

Follow-up. Parametrlashtirib bo'lmaydigan qism (masalan dinamik ustun/jadval nomi yoki ORDER BY yo'nalishi)ni qanday xavfsiz qilasiz? (Oq ro'yxat / allowlist orqali.)

13-bo'lim. NoSQL: MongoDB va Redis

S: MongoDB'da document model qanday ishlaydi? Aggregation pipeline nima? (Middle)

Ta'rif. MongoDB ma'lumotni BSON (binary JSON) hujjatlar (document) ko'rinishida, kolleksiyalarda (collection) saqlaydi. Aggregation pipeline — hujjatlarni bosqichlar (stage) ketma-ketligi orqali qayta ishlaydigan mexanizm.

Mexanizm. Har hujjat moslashuvchan tuzilmaga ega, ichma-ich (nested) obyekt va massivlarni saqlaydi — bog'liq ma'lumotni bir hujjatga jamlash JOINni yo'qotadi. Aggregation pipeline'da har stage ($match, $group, $sort, $project, $lookup) natijani keyingi stage'ga uzatadi — SQL'dagi WHERE GROUP BY SELECT mantig'iga o'xshash.

Kod/SQL misol:

javascript

// Har shahar bo'yicha jami savdo (SQL GROUP BY ekvivalenti)
db.orders.aggregate([
  { $match: { status: "paid" } },                 // WHERE
  { $group: { _id: "$city", total: { $sum: "$amount" } } },  // GROUP BY + SUM
  { $sort: { total: -1 } }                        // ORDER BY DESC
]);

Keng tarqalgan xato. Relational odat bilan MongoDB'da hamma narsani alohida kolleksiyaga bo'lib, keyin $lookup (JOIN) bilan yig'ish. MongoDB'da ko'pincha ma'lumotni birga o'qiladigan shaklda bir hujjatga joylash (embedding) to'g'riroq.

Follow-up. Embedding va referencing (havola) o'rtasida qanday tanlaysiz? Hujjatning 16MB limiti bunga qanday ta'sir qiladi?

S: Redis nima va uning asosiy ma'lumot tuzilmalari hamda foydalanish holatlari qanday? (Middle)

Ta'rif. Redis — ma'lumotni asosan xotirada (in-memory) saqlaydigan, juda tez key-value ma'lumotlar bazasi. U bir necha boy ma'lumot tuzilmasini qo'llab-quvvatlaydi.

Mexanizm. Xotirada ishlagani uchun o'qish/yozish mikrosekundlarda bajariladi. Tuzilmalar: String (kesh, hisoblagich), Hash (obyekt maydonlari), List (navbat/queue), Set (noyob to'plam), Sorted Set (reyting/leaderboard), Stream (event log). TTL bilan kalitni avtomatik muddati o'tadigan qilish mumkin. Ma'lumot ixtiyoriy tarzda diskka (RDB/AOF) saqlanadi.

Kod/SQL misol:

text

# Kesh (TTL bilan)
SET user:5:profile "{...}" EX 3600     # 1 soatdan keyin o'chadi

# Hisoblagich (atomik)
INCR page:views

# Leaderboard (Sorted Set)
ZADD leaderboard 1500 "ali"
ZREVRANGE leaderboard 0 9 WITHSCORES   # top 10

# Navbat (List)
LPUSH jobs "task1"
BRPOP jobs 0                            # bloklovchi olib chiqish

Keng tarqalgan xato. Redis'ni asosiy (birlamchi) ma'lumotlar bazasi sifatida ishlatib, bardoshlilikka to'liq ishonish. Xotira asosidagi bo'lgani uchun u ko'pincha kesh yoki yordamchi sifatida ishlatiladi; muhim ma'lumot bardoshli bazada saqlanadi.

Follow-up. Redis'da cache invalidation strategiyalarini (write-through, write-behind, cache-aside) tushuntiring.

S: Migration (migratsiya) nima va nega versiya nazoratida saqlanadi? (Middle)

Ta'rif. Migration — baza sxemasidagi o'zgarishni (jadval qo'shish, ustun o'zgartirish) kod sifatida, versiyalab yozish. Har migration oldinga (up) va orqaga (down) qadamga ega.

Mexanizm. Migratsiyalar tartib bilan bajariladi va baza qaysi migratsiyalar qo'llanganini maxsus jadvalda kuzatadi. Bu sxemani barcha muhitlarda (dev, staging, production) va jamoa a'zolari orasida bir xil va takrorlanadigan qiladi. Versiya nazorati (Git) bilan birga saqlanib, kod bilan sxema sinxron rivojlanadi.

Kod/SQL misol:

javascript

// migration: 20260706_add_status_to_orders
exports.up = (knex) =>
  knex.schema.table('orders', (t) => {
    t.string('status').defaultTo('pending').notNullable();
  });

exports.down = (knex) =>
  knex.schema.table('orders', (t) => t.dropColumn('status'));

Keng tarqalgan xato. Katta jadvalda ishlab chiqarishda bloklovchi migratsiya (masalan NOT NULL ustun qo'shish yoki index yaratish) bajarib, jadvalni qulflab qo'yish. Bunday holatda bosqichma-bosqich yoki CREATE INDEX CONCURRENTLY kabi bloklamaydigan usul kerak.

Follow-up. Ishlab chiqarishda "backward compatible" migratsiya nima va nega deploy bilan ikki bosqichda (expand/contract) qilinadi?

14-bo'lim. Amaliy SQL yozish

S: SQL yozing: har bir bo'lim (department) bo'yicha o'rtacha maoshni topib, faqat 3000 dan yuqorisini ko'rsating, kamayish tartibida. (Middle)

Mexanizm. GROUP BY department bilan guruhlaymiz, AVG(salary) bilan o'rtachani hisoblaymiz, HAVING bilan agregat shartni qo'llaymiz (WHERE emas), so'ng ORDER BY ... DESC bilan saralaymiz.

Kod/SQL misol:

sql

SELECT department,
       AVG(salary) AS avg_salary,
       COUNT(*)    AS emp_count
FROM employees
GROUP BY department
HAVING AVG(salary) > 3000
ORDER BY avg_salary DESC;

Keng tarqalgan xato. WHERE avg_salary > 3000 yozish — agregat HAVINGda bo'lishi kerak, va SELECTdagi alias (avg_salary)ni HAVINGda ishlatib bo'lmaydi (ba'zi bazalarda), shuning uchun AVG(salary) takrorlanadi.

Follow-up. Maoshi umuman kiritilmagan (NULL) xodimlar bu o'rtachaga qanday ta'sir qiladi?

S: SQL yozing: hech qachon buyurtma bermagan mijozlarni toping. (Middle)

Mexanizm. Uch xil yondashuv bor: LEFT JOIN ... IS NULL (anti-join), NOT EXISTS, NOT IN. NOT EXISTS odatda eng ishonchli, chunki NOT IN subquery NULL qaytarsa kutilmagan bo'sh natija beradi.

Kod/SQL misol:

sql

-- Yondashuv 1: LEFT JOIN + IS NULL (anti-join)
SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

-- Yondashuv 2: NOT EXISTS (odatda afzal)
SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (
    SELECT 1 FROM orders o WHERE o.customer_id = c.id
);

Keng tarqalgan xato. NOT IN (SELECT customer_id FROM orders) ishlatish — agar orders.customer_idda bironta NULL bo'lsa, NOT IN hech qanday qator qaytarmaydi (uch qiymatli mantiq tufayli). NOT EXISTS bu tuzoqdan xoli.

Follow-up. Uch yondashuvdan qay biri katta jadvalda tezroq va nega?

S: SQL yozing: har bir mijozning eng so'nggi buyurtmasini toping. (Senior)

Mexanizm. Bu "greatest-N-per-group" klassik masalasi. Eng toza yechim — window funksiya ROW_NUMBER() bilan har mijoz ichida buyurtmalarni sanaga qarab tartiblab, birinchisini olish.

Kod/SQL misol:

sql

-- Window funksiya bilan (afzal, o'qish oson)
WITH ranked AS (
    SELECT o.*,
           ROW_NUMBER() OVER (
               PARTITION BY customer_id
               ORDER BY created_at DESC
           ) AS rn
    FROM orders o
)
SELECT * FROM ranked WHERE rn = 1;

-- Correlated subquery bilan (alternativa)
SELECT * FROM orders o
WHERE created_at = (
    SELECT MAX(created_at) FROM orders o2
    WHERE o2.customer_id = o.customer_id
);

Keng tarqalgan xato. GROUP BY customer_id qilib, MAX(created_at) bilan birga boshqa ustunlarni (amount, product) tanlash. Bu ustunlar MAX qatoriga tegishli ekaniga kafolat yo'q — natija noto'g'ri qatorlarni aralashtiradi.

Follow-up. Bir mijozda ikki buyurtma aynan bir xil vaqtga (created_at) teng bo'lsa, ROW_NUMBER va RANK qanday farqli natija beradi?

S: SQL yozing: oylik daromadni va uning yig'indi (running total) o'sishini hisoblang. (Senior)

Mexanizm. Avval oyma-oy guruhlaymiz (date_trunc + GROUP BY), so'ng window funksiya SUM() OVER (ORDER BY ...) bilan yig'ma jami (running total) hisoblaymiz — bu har oygacha bo'lgan umumiy daromadni beradi.

Kod/SQL misol:

sql

WITH monthly AS (
    SELECT date_trunc('month', created_at) AS month,
           SUM(amount) AS revenue
    FROM orders
    GROUP BY 1
)
SELECT month,
       revenue,
       SUM(revenue) OVER (ORDER BY month) AS running_total
FROM monthly
ORDER BY month;

Keng tarqalgan xato. SUM(revenue) OVER () da ORDER BY qo'ymaslik — bunda window butun to'plamning umumiy yig'indisini beradi, "running" (bosqichma-bosqich o'suvchi) bo'lmaydi.

Follow-up. So'nggi 3 oylik ko'chma o'rtacha (moving average)ni qanday hisoblaysiz? (ROWS BETWEEN 2 PRECEDING AND CURRENT ROW.)

S: SQL yozing: ikki jadvalni (users va orders) birlashtirib, har foydalanuvchining ismi bilan jami sarflagan summasini ko'rsating; buyurtmasi yo'qlar 0 bilan ko'rinsin. (Middle)

Mexanizm. LEFT JOIN bilan barcha foydalanuvchini saqlaymiz (buyurtmasiz ham), SUMni COALESCE bilan o'raymiz — NULL (buyurtma yo'q) 0ga aylanadi.

Kod/SQL misol:

sql

SELECT u.id,
       u.name,
       COALESCE(SUM(o.amount), 0) AS total_spent
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.id, u.name
ORDER BY total_spent DESC;

Keng tarqalgan xato. INNER JOIN ishlatish — bu buyurtmasi yo'q foydalanuvchilarni butunlay chiqarib tashlaydi, "0 bilan ko'rinsin" sharti buziladi. Yana COALESCEni unutsa, ular NULL bo'lib chiqadi.

Follow-up. GROUP BYga u.nameni ham qo'shish shartmi? (Standart SQL'da ha — SELECTdagi har bir agregatsiz ustun GROUP BYda bo'lishi kerak.)

S: SQL yozing: ikkinchi eng yuqori maoshni toping (dublikatlarni hisobga olib). (Senior)

Mexanizm. Klassik intervyu savoli. DENSE_RANK() dublikat maoshlarni bir xil o'ringa qo'yadi, shuning uchun "ikkinchi eng yuqori" to'g'ri aniqlanadi. Alternativa — DISTINCT + OFFSET.

Kod/SQL misol:

sql

-- Yondashuv 1: DENSE_RANK (dublikatga bardoshli)
WITH ranked AS (
    SELECT salary,
           DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
    FROM employees
)
SELECT DISTINCT salary FROM ranked WHERE rnk = 2;

-- Yondashuv 2: DISTINCT + OFFSET
SELECT DISTINCT salary
FROM employees
ORDER BY salary DESC
OFFSET 1 LIMIT 1;

Keng tarqalgan xato. MAX(salary) WHERE salary < (SELECT MAX(salary) ...) ishlatish — bu ko'p holatda ishlaydi, lekin LIMIT 1 OFFSET 1 (DISTINCTsiz) dublikat eng yuqori maoshda noto'g'ri natija beradi. DENSE_RANK eng ishonchli.

Follow-up. N-chi eng yuqori maoshni (parametrlashtirilgan) qanday umumlashtirasiz?

Eng ko'p so'raladigan savollar

Quyidagilar intervyularda eng tez-tez uchraydigan savollar — ularni ravon, ovoz chiqarib tushuntira olishga tayyor bo'ling:

SQL va NoSQL farqi hamda qachon qaysi birini tanlaysiz? — Ma'lumot tuzilishi, yaxlitlik va masshtablash asosida asoslang.
JOIN turlarini misol bilan tushuntiring — Ayniqsa INNER va LEFT JOIN farqini, LEFT JOINda WHERE tuzog'ini bilib oling.
Index nima va u qanday tezlashtiradi? — B-tree, O(log n), va "qachon zararli" tomonini ayting.
ACID nima? — Har to'rt harfni bir jumla bilan ayta oling.
Isolation level'lar va anomaliyalar — Dirty / non-repeatable / phantom read jadvalini yodda tuting.
N+1 query muammosi — Aniqlash (so'rov loglari) va yechish (eager load / JOIN) ni tushuntiring.
Normalizatsiya (1NF/2NF/3NF) — Har birini bir misolli anomaliya bilan ayting.
Transaction va deadlock — Deadlock nega yuzaga keladi va retry strategiyasi.
CAP teoremasi — P majburiy, tanlov CP va AP orasida.
SQL injection'dan himoya — Doim parametrlangan so'rov, "escape yetarli emas".
GROUP BY va HAVING farqi — WHERE guruhlashdan oldin, HAVING keyin.
Window funksiya va GROUP BY farqi — Biri qatorlarni saqlaydi, biri siqadi.
Amaliy SQL: "ikkinchi eng yuqori maosh", "har mijozning so'nggi buyurtmasi", "buyurtma bermaganlar" — bularni yozib mashq qiling.
Connection pooling — Nega kerak va serverless'dagi tuzoq.
Replikatsiya va replication lag — "read-your-writes" muammosi.

Yakuniy maslahat: intervyuda SQL yozishda fikrlash tartibini ovoz chiqarib ayting (FROM JOIN WHERE GROUP BY HAVING SELECT ORDER BY). Bu bilim chuqurligini ko'rsatadi va xatoni erta ushlashga yordam beradi.

Ushbu fayl "Dasturlash kitobi" qo'shimcha materiallarining bir qismi — Intervyu bo'limi, 06-Database-SQL.

Izohlar (0)

Izoh yozish uchun kiring.

Hozircha izoh yo'q. Birinchi bo'ling!