✅ Ertalabki test javobi: NULL qatorlar chiqmaydi

SQL ikki qiymatli emas, uch qiymatli mantiq bilan ishlaydi: TRUE, FALSE va UNKNOWN.

NULL <> 'active' → UNKNOWN
NULL = NULL → UNKNOWN (ha, NULL o'ziga ham teng emas!)

WHERE esa faqat TRUE bo'lgan qatorlarni o'tkazadi. UNKNOWN — tashlab yuboriladi.

Yechimlar:

-- 1. Ochiq-oydin qo'shish
WHERE status <> 'active' OR status IS NULL

-- 2. NULL ni qiymatga aylantirish
WHERE COALESCE(status, 'none') <> 'active'

-- 3. PostgreSQL usuli
WHERE status IS DISTINCT FROM 'active'

Uchinchisi eng toza: IS DISTINCT FROM NULL ni oddiy qiymat kabi solishtiradi.

⚠️ Eng xavflisi shundaki, bunday so'rov xato bermaydi. Shunchaki qatorlar yo'qoladi — hisobotdagi raqam kamayadi, siz esa sezmaysiz.

💬 Sizning bazangizda qaysi ustunlar NULL bo'lishi mumkin? Bir tekshirib ko'ring 👇

🎯 Endi amaliyot: NULL: uch qiymatli mantiq tuzog'i
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

☕ Ertalabki masala: klassik intervyu savoli

Jadval: employees(id, name, department, salary)

Vazifa: har bir bo'limdagi eng yuqori maosh oladigan xodimni chiqaring. Bitta bo'limda bir xil maosh bilan ikki kishi bo'lsa — ikkalasi ham ro'yxatda bo'lsin.

SELECT ???
FROM employees
???

🎯 Bu savol ish suhbatlarida eng ko'p beriladigan uchlikdan biri. Kamida ikki xil yechimi bor.

✍️ O'z variantingizni izohda yozing — 20:00 da ikkala yechimni ham tahlil qilamiz 👇

🎯 Endi amaliyot: Har bo'limdagi eng yuqori maosh
Masala saytda ham bor — yozing, tizim javobingizni darhol tekshiradi 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

🪟 ROW_NUMBER, RANK, DENSE_RANK — farqi nimada?

Uchalasi ham qatorlarga raqam beradi, lekin teng qiymatlarda boshqacha yo'l tutadi.

Misol: ballar 100, 90, 90, 80

ROW_NUMBER() → 1, 2, 3, 4
Har qatorga noyob raqam. Teng bo'lsa ham farqlaydi (qaysi biri 2, qaysi biri 3 — tasodifiy, agar ORDER BY aniq bo'lmasa).

RANK() → 1, 2, 2, 4
Tenglar bir xil o'rin oladi, keyingi o'rin sakraydi. Sport natijalari shunday.

DENSE_RANK() → 1, 2, 2, 3
Tenglar bir xil o'rin oladi, sakrash yo'q.

SELECT
    name,
    score,
    ROW_NUMBER() OVER (ORDER BY score DESC) AS rn,
    RANK()       OVER (ORDER BY score DESC) AS rnk,
    DENSE_RANK() OVER (ORDER BY score DESC) AS drnk
FROM results;

PARTITION BY — guruh ichida sanash uchun:

ROW_NUMBER() OVER (
    PARTITION BY department
    ORDER BY salary DESC
)

Bu «har bo'lim ichida maosh bo'yicha tartiblab, 1 dan sanash» degani.

📌 Qaysi birini tanlash:
• dublikat o'chirish, «har guruhdan bittasi» → ROW_NUMBER
• «top 3», tenglar ham kirsin → DENSE_RANK
• haqiqiy reyting, o'rin sakrasin → RANK

🎯 Endi amaliyot: RANK va DENSE_RANK farqi
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

✅ Ertalabki masala yechimi: har bo'limdagi eng yuqori maosh

1-usul: window funksiya (zamonaviy, tavsiya etiladi)

WITH ranked AS (
    SELECT name, department, salary,
           RANK() OVER (PARTITION BY department
                        ORDER BY salary DESC) AS r
    FROM employees
)
SELECT name, department, salary
FROM ranked
WHERE r = 1;

Bu yerda RANK ishlatildi, chunki shartda «bir xil maosh bo'lsa ikkalasi ham» deyilgan. ROW_NUMBER bo'lsa faqat bittasi chiqardi.

2-usul: korrelyatsion subquery (eski bazalarda ham ishlaydi)

SELECT name, department, salary
FROM employees e
WHERE salary = (
    SELECT MAX(salary)
    FROM employees
    WHERE department = e.department
);

Qaysi biri yaxshi? Odatda window — jadval bir marta o'qiladi. Subquery esa har qator uchun ichki so'rovni qayta bajarishi mumkin (index bo'lmasa ayniqsa og'ir).

❌ Eng ko'p uchraydigan xato:

SELECT name, department, MAX(salary)
FROM employees
GROUP BY department;   -- xato!

Bu yerda name qaysi xodimniki ekani noma'lum. PostgreSQL xato beradi, MySQL esa tasodifiy ism qaytaradi — bu yanada yomon, chunki so'rov «ishlaydi».

💬 Siz qaysi usulni yozgan edingiz?

🎯 Endi amaliyot: Ikkinchi eng yuqori maosh
Shu mantiqning davomi — intervyu klassikasi 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

🔁 DISTINCT bilan «tuzatish» — eng qimmat odat

So'rov dublikat qaytardi. Ko'pchilik shu zahoti DISTINCT qo'shadi va davom etadi.

SELECT DISTINCT c.name, o.amount
FROM customers c
JOIN orders o ON o.customer_id = c.id;

Muammo: DISTINCT sababni emas, alomatni yashiradi. Dublikat paydo bo'lgan bo'lsa, demak JOIN kaliti o'ng jadvalda unikal emas. Va agar ikki mijozning summasi tasodifan teng bo'lsa — DISTINCT ulardan birini o'chirib tashlaydi. Hisobot jimgina noto'g'ri bo'ladi.

Avval dublikat borligini tekshiring:

SELECT email, COUNT(*)
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

Dublikat qatorlarni o'chirish (eng ishonchli usul — ROW_NUMBER):

WITH d AS (
    SELECT id,
           ROW_NUMBER() OVER (PARTITION BY email
                              ORDER BY created_at) AS rn
    FROM users
)
DELETE FROM users
WHERE id IN (SELECT id FROM d WHERE rn > 1);

Bu har bir email uchun eng eskisini qoldiradi, qolganini o'chiradi.

⚠️ DELETE yozishdan oldin doim shu so'rovni SELECT bilan bir marta ishga tushiring — nima o'chishini ko'ring.

📌 DISTINCT yozgingiz kelsa, avval bitta savol bering: bu dublikat qayerdan keldi?

🎯 Endi amaliyot: Takrorlangan email larni topish
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

✅ Ertalabki test javobi: 4-o'rin

RANK() tenglardan keyin o'rinni sakratadi: 1, 2, 2, 4. Uchinchi o'rin umuman bo'lmaydi.
DENSE_RANK() esa sakratmaydi: 1, 2, 2, 3.

Amalda bu qayerda muhim?

Vazifa: «top 3 mahsulot» ro'yxatini chiqaring.

-- DENSE_RANK: teng natijalar ham kiradi
WHERE drnk <= 3   -- 3 ta o'rin, lekin 4-5 qator bo'lishi mumkin

-- ROW_NUMBER: qat'iy 3 qator
WHERE rn <= 3

Agar boshliq «menga aniq 3 qator kerak» desa — ROW_NUMBER. Agar «uchinchi o'rinni bo'lishganlar ham chiqsin» desa — DENSE_RANK.

Bu texnik emas, biznes savoli. Shuning uchun analitik so'rov yozishdan oldin aniqlab oladi.

💬 Sizning ishingizda «top N» qanday hisoblanadi?

🎯 Endi amaliyot: Takroriy yozuvlarni tozalash
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

☕ Ertalabki masala: ketma-ket kunlar

Jadval: logins(user_id, login_date) — har bir kirish bitta qator.

Vazifa: kamida 3 kun ketma-ket tizimga kirgan foydalanuvchilarni toping.

Masalan:
• user 1 → 5, 6, 7-oktabr ✅
• user 2 → 5, 6, 8-oktabr ❌

SELECT user_id
FROM logins
???

⚠️ Ogohlantirish: bu masala GROUP BY bilan yechilmaydi. Bu yerda boshqa usul kerak.

🎯 Bu «gaps and islands» deb ataladigan klassik masala. Uni bilgan odam intervyuda darrov ajralib turadi.

✍️ Fikringizni izohda yozing, 13:00 da to'liq tahlil qilamiz 👇

🎯 Endi amaliyot: 3+ ketma-ket kun kirgan foydalanuvchilar
Masala saytda tayyor turibdi — urinib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

🏝 Gaps and islands: ketma-ketlikni qanday topish kerak

Ertalabki masalaning yechimi. Butun sir bitta hiylada.

Hiyla: agar sanalar ketma-ket bo'lsa, ularning tartib raqami ham ketma-ket o'sadi. Demak sana − tartib_raqami ayirmasi bitta «orolcha» ichida o'zgarmaydi.

WITH t AS (
    SELECT user_id, login_date,
           login_date - (ROW_NUMBER() OVER (
               PARTITION BY user_id
               ORDER BY login_date
           ) * INTERVAL '1 day') AS grp
    FROM (SELECT DISTINCT user_id, login_date FROM logins) x
)
SELECT user_id
FROM t
GROUP BY user_id, grp
HAVING COUNT(*) >= 3;

Nima bo'lyapti?
5, 6, 7-oktabr → raqamlari 1, 2, 3 → ayirma har uchalasida bir xil → bitta guruh, 3 qator → shart bajarildi.
5, 6, 8-oktabr → 8 da ayirma o'zgaradi → yangi guruh boshlanadi → hech qaysi guruhda 3 ta yo'q.

⚠️ SELECT DISTINCT shart: bitta kunda ikki marta kirgan bo'lsa, raqamlar siljib ketadi va natija buziladi.

📌 Xuddi shu usul boshqa joylarda ham ishlaydi:
• streak hisoblash (ketma-ket kunlar)
• uzluksiz ishlagan davrlar
• sensor ma'lumotlaridagi uzilishlar
• abonement to'lovlaridagi bo'shliqlar

💬 Bu usulni bilarmidingiz? Boshqa yechim taklif qila olasizmi?

🎯 Endi amaliyot: Eng uzun g'alabalar seriyasi
Xuddi shu usul bilan yechiladi — mustahkamlab oling 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

🎯 SQL ni o'qib emas, yozib o'rganasiz

Bugungi «gaps and islands» masalasini o'qib chiqdingiz. Tushundingiz. Endi rostini aytaylik: bir haftadan keyin uni o'zingiz noldan yoza olasizmi?

Ko'pchilik yoza olmaydi. Chunki o'qish — tanish tuyg'usi beradi, ko'nikma bermaydi. Ko'nikma faqat bo'sh oynaga so'rov yozib, xato olib, tuzatib paydo bo'ladi.

Shuning uchun sqlmaster.uz qurildi:

🔹 195 ta masala — SELECT asoslaridan window funksiya va CTE gacha
🔹 Real schemalar — Uzum, Click, taksi, bank jadvallari. O'quv misollari emas, ishdagi vaziyatlar
🔹 Yozasiz — tizim darrov tekshiradi. To'g'ri javobni emas, sizning so'rovingiz natijasini solishtiradi
🔹 Muhokama bo'limi — boshqalarning yechimini ko'rasiz. Bitta masalaning 5 xil yechimi bo'ladi
🔹 Bosqichma-bosqich — Oson → O'rtacha → Qiyin

💡 Birinchi 50 ta masala mutlaqo bepul. Ro'yxatdan o'tish 30 soniya, karta kerak emas.

Bugun 3 ta masala yeching. Ertaga yana 3 ta. Bir oydan keyin intervyuda «JOIN yozib bering» degan gap sizni cho'chitmaydi.

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

☕ Ertalabki savol: qaysi biri tezroq?

Ikkala so'rov ham bir xil natija beradi — buyurtma bergan mijozlar ro'yxati.

-- 1-variant
SELECT * FROM customers c
WHERE c.id IN (SELECT customer_id FROM orders);

-- 2-variant
SELECT * FROM customers c
WHERE EXISTS (
    SELECT 1 FROM orders o
    WHERE o.customer_id = c.id
);

Sizningcha qaysi biri tezroq ishlaydi?

A) IN tezroq
B) EXISTS tezroq
C) Farqi yo'q

✍️ Javobingizni izohda yozing. Kechqurun 20:00 da query plan bilan ko'rsataman 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

🐌 Index bor, lekin so'rov sekin. Nega?

Index yaratilgan bo'lsa ham, baza uni ishlatmasligi mumkin. Mana eng ko'p uchraydigan 5 holat:

1️⃣ Ustunga funksiya qo'llansa

WHERE DATE(created_at) = '2026-10-06'   -- index ishlamaydi
WHERE created_at >= '2026-10-06'
  AND created_at <  '2026-10-07'        -- index ishlaydi

Index created_at qiymatlarini saqlaydi, DATE(created_at) natijasini emas.

2️⃣ LIKE boshida foiz bo'lsa
LIKE 'Ali%' — ishlaydi
LIKE '%Ali' — ishlamaydi (index alifbo tartibida, boshi noma'lum)

3️⃣ Tip mos kelmasa
WHERE phone = 998901234567 — phone matn ustuni bo'lsa, baza har qatorni songa aylantiradi va index chetda qoladi. Tirnoq qo'ying.

4️⃣ OR ishlatilsa
WHERE a = 1 OR b = 2 — ko'pincha to'liq skan. UNION ALL bilan ikki so'rovga bo'lish tezroq bo'lishi mumkin.

5️⃣ Jadval kichik bo'lsa
1000 qatorli jadvalda to'liq o'qish indexdan tez. Bu xato emas — optimizator to'g'ri qaror qilyapti.

📌 Taxmin qilmang, tekshiring:

EXPLAIN ANALYZE
SELECT ...;

Natijada Seq Scan ko'rsangiz — index ishlamayapti. Index Scan yoki Bitmap Index Scan ko'rsangiz — ishlayapti.

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

✅ Javob: C — zamonaviy bazalarda farqi deyarli yo'q

PostgreSQL va SQL Server optimizatori IN va EXISTS ni ko'pincha bir xil planga aylantiradi (semi-join). Ya'ni «EXISTS doim tezroq» degan eski maslahat bugun har doim ham to'g'ri emas.

Lekin ikkita muhim farq bor 👇

1️⃣ NULL bilan xulq-atvor. NOT IN ichida bitta NULL bo'lsa, natija butunlay bo'sh chiqadi. NOT EXISTS da bunday muammo yo'q. Shuning uchun inkorda doim NOT EXISTS.

2️⃣ Ichki ro'yxat katta bo'lsa. IN (1, 2, 3, ... 10000) ko'rinishidagi qo'lda yozilgan uzun ro'yxat sekin ishlaydi — vaqtinchalik jadval yoki JOIN afzal.

Uchinchi variant — JOIN:

SELECT DISTINCT c.*
FROM customers c
JOIN orders o ON o.customer_id = c.id;

⚠️ Bu yerda DISTINCT kerak bo'ldi, chunki mijozning 5 ta buyurtmasi bo'lsa 5 marta chiqadi. EXISTS da bu muammo yo'q — u «bormi?» degan savolga javob beradi, ko'paytirmaydi.

📌 Xulosa: «bor-yo'qligini» tekshirish uchun — EXISTS. Ustun kerak bo'lsa — JOIN.

💬 EXPLAIN ANALYZE ni ishlatib ko'rganmisiz?

🎯 Endi amaliyot: EXISTS va IN — qayta yozish
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

☕ Ertalabki masala: oylik o'sish

Jadval: sales(sale_date, amount)

Vazifa: har oy uchun umumiy savdo va o'tgan oyga nisbatan o'sish foizini chiqaring.

Natija shunday ko'rinishi kerak:

oy        jami        o'sish_%
2026-08   120 000     —
2026-09   150 000     +25.0
2026-10   135 000     -10.0

🎯 Bu hisobot har bir analitikdan haftada bir marta so'raladi. Ikki bosqichda yechiladi: avval oy bo'yicha guruhlash, keyin o'tgan qatorga murojaat.

✍️ Qaysi funksiya kerakligini bilasizmi? Izohda yozing, kechqurun yechamiz 👇

🎯 Endi amaliyot: Oylik o'sish foizi
Masala saytda ham bor — yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

📅 Sanalar bilan ishlashda 3 ta tuzoq

1️⃣ BETWEEN va timestamp

WHERE created_at BETWEEN '2026-01-01' AND '2026-01-31'

31-yanvar soat 10:00 da yaratilgan yozuv chiqmaydi. Chunki '2026-01-31' aslida 2026-01-31 00:00:00 degani. Butun bir kun yo'qoladi.

✅ To'g'ri usul — yarim ochiq oraliq:

WHERE created_at >= '2026-01-01'
  AND created_at <  '2026-02-01'

Bu ham to'g'ri, ham indexni ishlatadi.

2️⃣ Oy bo'yicha guruhlash

-- PostgreSQL
SELECT DATE_TRUNC('month', sale_date) AS oy, SUM(amount)
FROM sales GROUP BY 1 ORDER BY 1;

-- MySQL
SELECT DATE_FORMAT(sale_date, '%Y-%m') AS oy, SUM(amount)
FROM sales GROUP BY 1 ORDER BY 1;

3️⃣ Vaqt zonasi
Server UTC da, siz Toshkentdasiz. Yarim tundan keyingi buyurtma «kechagi kun» bo'lib hisoblanishi mumkin. Kunlik hisobot 5 soatga siljiydi:

SELECT DATE_TRUNC('day',
    created_at AT TIME ZONE 'Asia/Tashkent') AS kun
FROM orders GROUP BY 1;

📌 Kunlik hisobotdagi raqam boshqa tizimdagi raqamga to'g'ri kelmayotgan bo'lsa — birinchi navbatda shu uchtasini tekshiring.

🎯 Endi amaliyot: Oy kesimida daromad
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

✅ Yechim: oylik o'sish foizi — LAG bilan

WITH oylik AS (
    SELECT DATE_TRUNC('month', sale_date) AS oy,
           SUM(amount) AS jami
    FROM sales
    GROUP BY 1
)
SELECT
    oy,
    jami,
    LAG(jami) OVER (ORDER BY oy) AS otgan_oy,
    ROUND(
        100.0 * (jami - LAG(jami) OVER (ORDER BY oy))
        / NULLIF(LAG(jami) OVER (ORDER BY oy), 0),
    1) AS osish_foiz
FROM oylik
ORDER BY oy;

Uchta muhim nuqta:

🔹 LAG(jami) — oldingi qatordagi qiymatni oladi. Aksincha keyingisi kerak bo'lsa — LEAD.

🔹 NULLIF(x, 0) — nolga bo'lishdan himoya. O'tgan oy savdosi 0 bo'lsa, so'rov xato bermay, NULL qaytaradi. Bu kichik detal ko'p hisobotni buzadi.

🔹 100.0 — nuqta bilan. Butun sonlar bo'linsa, ba'zi bazalarda natija ham butun bo'lib qoladi: 0.25 o'rniga 0.

💡 Birinchi oyda osish_foiz NULL bo'ladi — solishtiradigan oy yo'q. Hisobotda chiroyli ko'rinishi uchun: COALESCE(..., 0) yoki shunchaki chiziqcha.

🔹 Window funksiyalar bo'yicha saytda 37 ta masala bor — LAG, LEAD, SUM OVER, NTILE bilan mashq qilish uchun.

💬 LAG ni bilmagan bo'lsangiz, bugun bitta hisobotingizni shu bilan qayta yozib ko'ring.

🎯 Endi amaliyot: Payme: oylik o'sish
Real keys — o'sha LAG bilan yechiladi 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

♻️ CTE: uzun so'rovni o'qiladigan qilish

WITH — so'rov ichidagi vaqtinchalik nom. Uch qavat ichma-ich subquery o'rniga bosqichma-bosqich mantiq:

WITH faol AS (
    SELECT id, name FROM customers
    WHERE status = 'active'
),
buyurtma AS (
    SELECT customer_id, SUM(amount) AS jami
    FROM orders
    WHERE created_at >= '2026-01-01'
    GROUP BY customer_id
)
SELECT f.name, COALESCE(b.jami, 0) AS jami
FROM faol f
LEFT JOIN buyurtma b ON b.customer_id = f.id
ORDER BY jami DESC;

Bir xil natijani subquery bilan ham olish mumkin, lekin CTE ni yuqoridan pastga o'qiysiz — xuddi retsept kabi.

RECURSIVE CTE — o'ziga murojaat qiladi. Ierarxiya uchun ideal: kim kimga bo'ysunadi?

WITH RECURSIVE zanjir AS (
    -- 1. Boshlang'ich: rahbari yo'q xodim
    SELECT id, name, manager_id, 1 AS daraja
    FROM employees
    WHERE manager_id IS NULL

    UNION ALL

    -- 2. Har qadamda bir pog'ona pastga
    SELECT e.id, e.name, e.manager_id, z.daraja + 1
    FROM employees e
    JOIN zanjir z ON e.manager_id = z.id
)
SELECT * FROM zanjir ORDER BY daraja;

📌 Qayerda kerak: tashkilot tuzilmasi, kategoriya daraxti, kommentlar ostidagi javoblar, yo'nalishlar zanjiri.

⚠️ Rekursiyada doim to'xtash sharti bo'lsin. Ma'lumotda halqa bo'lsa (A → B → A), so'rov cheksiz aylanadi.

🎯 Endi amaliyot: Uch bosqichli CTE zanjiri
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

✅ Ertalabki test javobi: yo'q, tushmaydi

BETWEEN '2026-01-01' AND '2026-01-31' aslida shu degani:

created_at >= 2026-01-01 00:00:00
created_at <= 2026-01-31 00:00:00

Ya'ni 31-yanvarning butun kuni — 00:00:01 dan 23:59:59 gacha — tushib qoladi.

Oyiga bir kun. Yiliga 12 kun. Hisobotda esa hech qanday xato belgisi yo'q: so'rov ishlaydi, raqam chiqadi, shunchaki kamroq.

Yodda tuting:
✅ >= boshi AND < keyingi_boshi — har doim to'g'ri
❌ BETWEEN faqat date tipida xavfsiz
❌ <= '2026-01-31 23:59:59' — deyarli to'g'ri, lekin millisekundlar yo'qoladi

💡 Amaliy maslahat: hisobot yozgach, natijani boshqa manba bilan solishtiring. Raqam 1–3% ga farq qilsa, birinchi gumondor — sana chegarasi.

💬 Shu xato tufayli hisobotingiz noto'g'ri chiqqanmi? Izohda bo'lishing 👇

🎯 Endi amaliyot: Rekursiv: sotuvsiz kunlarni to'ldirish
Sana bilan ishlashning keyingi bosqichi 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

☕ Ertalabki masala: har kategoriyada top 3

Jadval: products(id, name, category, sales_count)

Vazifa: har bir kategoriya bo'yicha eng ko'p sotilgan 3 ta mahsulotni chiqaring.

SELECT category, name, sales_count
FROM products
???

⚠️ Diqqat: ORDER BY sales_count DESC LIMIT 3 ishlamaydi. U butun jadvaldan 3 ta qator beradi, har kategoriyadan emas.

🎯 Bu masala «top N per group» deb ataladi va intervyularda doim uchraydi.

✍️ Yechimingizni izohda yozing — kechqurun tahlil qilamiz 👇

🎯 Endi amaliyot: Har kategoriyada top 3 mahsulot
Masala saytda ham bor — yeching, tizim tekshiradi 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz