CROSS JOIN — bir relationdagi har bir satrni ikkinchi relationdagi har bir satr bilan juftlab, Cartesian product hosil qiladigan SQL operatori. Chap tomonda m, o‘ng tomonda n satr bo‘lsa, natija odatda m × n satrdan iborat bo‘ladi.
Sintaksis va ma’no
Ranglar bilan o‘lchamlarning barcha variantlarini yaratish:
SELECT c.name AS color, s.name AS size
FROM colors AS c
CROSS JOIN sizes AS s;
Uch rang va to‘rtta o‘lcham 12 kombinatsiya beradi. CROSS JOINda ON predicate bo‘lmaydi, chunki har bir juft mos hisoblanadi. Vergul bilan yozilgan eski FROM colors, sizes sintaksisi ham Cartesian product berishi mumkin, ammo aniq CROSS JOIN niyatni yaxshiroq ko‘rsatadi.
Amaliy qo‘llanishlar
Cartesian product doim xato emas. U barcha mumkin bo‘lgan konfiguratsiyalar, sana va kategoriya matritsasi, test parametrlar kombinatsiyasi yoki hisobotdagi yetishmayotgan kataklarni yaratishda ishlatiladi. Masalan, calendar jadvalidagi har kunni filiallar ro‘yxati bilan cross join qilib, sotuv bo‘lmagan kunlarni ham nol bilan ko‘rsatish mumkin.
Kichik bir qatorli configuration subqueryni katta jadvalga cross join qilish global parametrni har satrga ulaydi. Lateral join yoki mahsulotga xos CROSS APPLY esa o‘ng tomondagi subqueryni chap satr qiymatiga bog‘lab bajaradi; bu oddiy CROSS JOINdan semantik jihatdan farq qiladi.
Tasodifiy Cartesian product
Join predicate unutib qoldirilsa, katta Cartesian product yuzaga keladi. Bir million va yuz ming satrli jadvallar nazariy yuz milliard kombinatsiya beradi. Natija clientga to‘liq qaytmasa ham, oraliq hisob CPU, xotira va temporary diskni band qilishi mumkin.
Zamonaviy SQL sintaksisida bog‘lanadigan jadvallar uchun INNER JOIN ... ON ... yozish bunday xatoni ko‘rinadigan qiladi. Code reviewda har joinning cardinalitysi va biznes aloqasi tekshiriladi. Faqat natijaga DISTINCT qo‘shish yetishmagan join shartini tuzatmaydi.
Filter bilan bog‘lanish
Nazariy jihatdan CROSS JOINdan keyingi WHERE a.id = b.a_id inner join natijasiga teng bo‘lishi mumkin. Optimizer ko‘pincha predicate’ni join sharti sifatida taniydi. Shunga qaramay INNER JOIN ... ON bog‘lanish va global filterlarni ajratadi, outer joinga o‘tganda xatoni kamaytiradi.
WHERE ayrim kombinatsiyalarni keyin chiqarib tashlasa ham, optimizer shartni erta qo‘llashga urinadi. Murakkab yoki non-deterministic expressionda bu imkoniyat cheklanishi mumkin. Query plan haqiqiy bajarilish tartibini ko‘rsatadi.
Hajmni boshqarish
CROSS JOINdan oldin har tomonning taxminiy satrlar soni hisoblanadi. Kalendar diapazoni, aktiv elementlar yoki kerakli tenant WHERE bilan oldindan cheklanadi. Generatsiya qilinadigan kombinatsiyalar uchun yuqori limit va timeout qo‘yish foydali.
Natijani pagination qilish hisobning asosiy kattaligini yo‘qotmaydi: database baribir ko‘p kombinatsiyani ko‘rib chiqishi mumkin. Katta variantlar to‘plami kerak bo‘lsa, oqim tarzida ishlash, batchlarga bo‘lish yoki faqat haqiqiy mavjud kombinatsiyalarni saqlovchi alohida jadval ma’qul bo‘lishi mumkin.
Dimension jadvallarini CROSS JOIN qilib hisobot skeleti yaratilganda, fakt jadvali unga LEFT JOIN qilinadi va mavjud bo‘lmagan o‘lchovlar nolga aylantiriladi. NULLni 0ga almashtirish faqat “hodisa bo‘lmagan” ma’nosi tasdiqlanganda to‘g‘ri; o‘lchov kelmagan yoki kechikkan bo‘lsa nullni saqlash data sifatini ko‘rsatadi. Matritsa donadorligi hisobot kontraktida aniq yoziladi.
Bog‘liq tushunchalar
Cartesian product, INNER JOIN, Join predicate, Lateral join, CROSS APPLY, Cardinality, Query plan, SQL