---

Gdy René Descartes w XVII wieku połączył geometrię z algebrą, dał światu coś więcej niż tylko współrzędne. Dał intuicję, że „punkt” można opisać parą liczb, a dwie listy liczb – przekształcić w nową przestrzeń wszystkich możliwych kombinacji. Ta prosta myśl – dziś znana jako iloczyn kartezjański – stała się filarem nowoczesnej teorii zbiorów, bazy danych i… finansów.

W czasach, gdy przedsiębiorstwa generują miliardy rekordów dziennie, umiejętność sensownego łączenia tabel to być albo nie być analityka. CROSS JOIN – czyli kartezjańskie łączenie w SQL – często uchodzi za „przycisk czerwony”: potrafi stworzyć wykładniczo wielkie zbiory i wyłączyć serwer. Ale w odpowiednich rękach staje się skalpelem, dzięki któremu przygotujemy scenariusze ryzyka, wygenerujemy kalendarz roboczy czy przeprowadzimy stress-test marży odsetkowej.

W tym artykule przejdziemy drogę od czystej matematyki do praktycznych zapytań. Pokażę, jak zobrazować produkt kartezjański talią kart, jak CROSS JOIN różni się od INNER JOIN, kiedy „eksplozja wierszy” jest warta świeczki i wreszcie – jak finansista może wykorzystać to narzędzie do symulacji każdego możliwego zdarzenia. Przygotuj się na sporo kodu SQL, kilka trików optymalizacyjnych i dużą dawkę przykładów z życia. Jeśli kiedykolwiek zastanawiałeś się, dlaczego Twoje zapytanie zwróciło miliard wierszy zamiast miliarda dolarów, czytaj dalej – czas oswoić kartezjańskiego potwora.

---

Fundament matematyczny iloczynu kartezjańskiego

Definicja formalna

Matematycy lubią precyzję, więc zaczynamy od aksjomatu: iloczynem kartezjańskim dwóch zbiorów A i B nazywamy zbiór wszystkich uporządkowanych par (a, b), gdzie a ∈ A, b ∈ B. Notujemy go A × B. Ta drobna zmiana – kolejność elementów – odróżnia parę od zwykłej listy: (a, b) ≠ (b, a), chyba że a = b lub jeden ze zbiorów jest pusty (Wikipedia).

Co daje nam taka konstrukcja? Po pierwsze, fundament relacji binarnych. Relacja to dowolny podzbiór iloczynu kartezjańskiego. Kiedy na studiach spotykasz słowo „funkcja”, tak naprawdę widzisz szczególny przypadek relacji, w której każdy element A łączy się z dokładnie jednym elementem B. Po drugie, „produkt” nie kończy się na dwóch zbiorach – możemy rozszerzać go na trójki, czwórki itd., zapisując A × B × C …

W praktyce finansowej taka abstrakcja przekłada się na macierze: portfel aktywów (zbiór A) × scenariusze rynkowe (zbiór B) → macierz zysków i strat. Każdy wiersz macierzy to kombinacja „aktywo–scenariusz”. Bez idei iloczynu kartezjańskiego nie moglibyśmy w ogóle mówić o Value at Risk czy stress-testach. I chociaż w SQL-u produkt pojawia się pod maską CROSS JOIN-a, jego rodowód jest czysto matematyczny.

Podsumowując: iloczyn kartezjański to operator kompletności – tworzy wszystkie możliwe pary, dając nam pełny przegląd kombinacji. Kiedy potrzebujesz wyczerpującego scenariusza, jest bezcenny; kiedy zależy Ci na szybkości, bywa groźny. Za chwilę zobaczysz, jak z tej broni korzystać odpowiedzialnie.

Własności i notacja

Produkt kartezjański ma kilka cech, które przydają się każdemu, kto potem pisze zapytania:

1. Nie jest przemienny – A × B ≠ B × A, bo kolejność pól w tabeli ma znaczenie. Błąd w kolejności kolumn potrafi zrujnować import danych.
2. Nie jest łączny bez nawiasów: (A × B) × C ≠ A × (B × C). W SQL-u zobaczysz to w planie zapytania – kolejność joinów zmienia koszty obliczeń.
3. Rozmiar rośnie multiplikatywnie – |A × B| = |A| · |B|. Jeśli masz 1 000 kont i 365 dni kalendarzowych, CROSS JOIN zwróci 365 000 wierszy. Z matematyki wynika więc, że każde dodatkowe złączenie zwiększy liczbę rekordów wykładniczo.
4. Można go filtrować – przyporządkowanie relacji binarnych do podzbiorów A × B od razu sugeruje, że INNER JOIN to nic innego jak CROSS JOIN z warunkiem WHERE. Ta obserwacja uprości Ci debugowanie zapytań.

W finansach szczególnie ważna jest własność trzecia. Iloczyn kont × daty × scenariusze ryzyka może rozrosnąć się do milionów wierszy, a jednak każdy z nich bywa krytyczny przy stress-testach. Dlatego w kolejnych sekcjach pokażę, jak opanować tę „eksplozję” bez utracenia kompletności danych.

---

Iloczyn kartezjański na przykładach wizualnych

Talia kart i układ współrzędnych

Wyobraź sobie standardową talię 52 kart. Rangi (A, K, Q, …, 2) tworzą zbiór 13-elementowy, kolory (♠, ♥, ♦, ♣) – zbiór 4-elementowy. Gdy mnożysz te zbiory, dostajesz 13 × 4 = 52 unikalne pary (rangę, kolor) – czyli całą talię, nic dodać, nic ująć (Wikipedia).

Dlaczego to tak eleganckie? Bo pokazuje intuicję kompletności: nie pomijasz żadnej karty, nie tworzysz duplikatu. W SQL-u myślisz podobnie – masz tabelę Ranks (13 wierszy) i Suits (4 wiersze); CROSS JOIN zwróci 52 wiersze, każdy opisujący kartę.

Jeśli przesuniesz się z metafory kart do układu współrzędnych, zobaczysz to samo zjawisko geometrycznie: ℝ × ℝ to cała płaszczyzna. Jeden punkt = jedna para liczb. W finansach powiedzielibyśmy: każda para (czas, kurs EUR/PLN) to punkt na wykresie ceny.

Co więcej, przykład talii kart uczy Cię, że produkt kartezjański nie jest losowy – kombinacje tworzą uporządkowaną przestrzeń. Kiedy generujesz scenariusze ryzyka, zależy Ci właśnie na systematycznym pokryciu przestrzeni parametrów: stóp procentowych, inflacji, kursu walutowego. Dzięki CROSS JOIN-owi zrobisz to w trzech linijkach kodu.

Diagram Venna w trzech wymiarach

Klasyczny diagram Venna łączy dwa zbiory A i B na płaszczyźnie, podkreślając ich część wspólną. Iloczyn kartezjański wymyka się jednak dwuwymiarowej ilustracji, bo on tworzy… nową oś. Wyobraź sobie zbiory A i B jako dwa ortogonalne wymiary. Ich iloczyn to siatka punktów, każdy o koordynatach (a, b).

Gdy dodasz trzeci zbiór C, zamiast płaszczyzny dostajesz sześcian. W analityce finansowej taki trójwymiarowy grid pojawia się np. przy symulacji trzech stóp %: krótkoterminowej, średniej i długiej. W SQL-u wystarczy złączyć trzy tabele CROSS JOIN-em, żeby stworzyć sześcienną siatkę wszystkich możliwych kombinacji poziomów stóp.

Co ważne, sześcian ma nie 9, lecz 3³ = 27 wierzchołków – i ta liczba rośnie wykładniczo. Dlatego wizualizacja pomaga oszacować koszt obliczeń: jeżeli każda zmienna scenariusza przyjmie 10 wartości, a Ty połączysz 6 tabel, generator scenariuszy zwróci milion wierszy (10⁶). Zanim uruchomisz zapytanie, upewnij się, że potrzebujesz każdej kombinacji; w przeciwnym razie klasyczny Venna-Cube zamieni się w Cube-Of-Doom.

---

Relacyjny model danych a produkt kartezjański

Od zbiorów do rekordów

Relacyjna baza danych to nic innego, jak praktyczna implementacja teorii zbiorów. Każda tabela jest zbiorem krotek, a JOIN to operacja na zbiorach krotek. CROSS JOIN oddaje „czysty” iloczyn kartezjański: łączy każdą krotkę z każdą bez warunku selekcji. W standardzie SQL ANSI‐92 składnia jest prosta:

SELECT *
FROM   Portfolio  -- 100 wierszy
CROSS  JOIN Scenario;  -- 250 wierszy

Rezultat? 25 000 wierszy. Jeśli dodałbyś trzecią tabelę Dates (365 wierszy), powstałby zbiór 9 125 000 wierszy. Ta prosta kalkulacja pokazuje, dlaczego projektanci baz unikają przypadkowych CROSS JOIN-ów.

Jednak są momenty, gdy potrzebujesz pełnej siatki: kalendarz x scenariusz x produkt finansowy. W czasach IFRS 9 i Bazel III banki muszą liczyć oczekiwane straty (ECL) dla każdego kontraktu w milionach kombinacji dat i scenariuszy. Bez produktu kartezjańskiego byłoby to niemożliwe.

Normalizacja a redundancja kombinacji

Dobre modele danych uczą: usuń redundancję, normalizuj do trzeciej postaci (3NF). Paradoks? CROSS JOIN generuje redundancję z pre medytacją. Pętla „każdy z każdym” wielokrotnie powiela te same dane w nowych kombinacjach. […]

---

Zastosowania produktu kartezjańskiego w finansach

Zanim zagłębimy się w kody SQL, zatrzymaj się na chwilę i pomyśl o tym, jak często w codziennej pracy finansisty potrzebujesz „pełnej siatki” wszystkich możliwych kombinacji danych. Zamykasz miesiąc i musisz policzyć przychody dla każdego dnia, waluty i oddziału? Symulujesz stres scenariuszowy i chcesz zobaczyć, co stanie się z kapitałem przy każdej możliwej kombinacji stopy procentowej, kursu EUR/PLN i spreadu kredytowego? W każdym z tych zadań leży ukryty iloczyn kartezjański. To właśnie CROSS JOIN stworzy bazę, dzięki której później zastosujesz warunki, filtry i agregacje, by wydobyć z danych esencję ryzyka lub rentowności. W praktyce produkt kartezjański pełni dwie przeciwstawne role: generatora obszaru scenariuszy oraz inicjatora tabeli wymiarów w hurtowniach danych. Ten podwójny charakter bywa mylący, lecz zrozumienie go pozwala świadomie zdecydować, kiedy warto „wysadzić” tabelę, a kiedy rozsądniej będzie użyć bardziej oszczędnych technik łączenia.

Budowa kalendarza roboczego

Wyobraź sobie, że analityk ma wyliczyć średnie saldo na rachunku kredytowym dla każdego roboczego dnia roku, a w sprawozdaniu wymaga się również weekendów, świąt i tzw. dni pomostowych. Najszybszy sposób? Budujesz tabelę DimDates z wszystkimi datami w zakresie – powiedzmy 2000–2030. Potem cross-joinujesz ją z listą WorkdayFlags, zawierającą typy dni: WEEKDAY, WEEKEND, HOLIDAY, BRIDGE.

SELECT d.Date,
       f.Day_Type
FROM   DimDates  AS d
CROSS  JOIN WorkdayFlags AS f;

Na pierwszy rzut oka to szalony pomysł, bo z 11 000 dat robi się 44 000 rekordów. Ale popatrz na korzyści: z jednej kwerendy wyciągasz dowolne przekroje, a dzięki kolumnie Day_Type możesz w locie filtrować interesujące Cię dni. Potrzebujesz raportu typu „Średnie saldo tylko z dni roboczych”? Wystarczy dodać WHERE f.Day_Type = 'WEEKDAY'. Przy raporcie Value at Risk chcesz brać pod uwagę wyłącznie sesje giełdowe – filtrujesz na HOLIDAY = 'N’. Niczego nie przepisujesz, nie duplikujesz kodu, bo raz wygenerowana siatka dat × typ dni zostaje w hurtowni na lata, a CROSS JOIN to zaledwie ułamek sekundy na współczesnym silniku kolumnowym.

Generowanie siatki scenariuszy ryzyka

Risk managerzy kochają macierze „co-by-było-gdyby”. Zamiast pracować na jednym baseline’ie, chcą sprawdzić, jak zachowa się marża, płynność i wymogi kapitałowe pod wpływem skoku stóp procentowych, wahania kursów walut i spadku cen akcji. Najprostsza metoda to stworzyć trzy niewielkie tabele: RatesShock (np. −200 pb, −100 pb, 0, +100 pb, +200 pb), FxShock (−20 %, −10 %, 0 %, +10 %, +20 %) i EquityShock (−40 %, −20 %, 0 %, +20 %, +40 %). Sam CROSS JOIN wykona gigantyczną robotę:

SELECT r.Shift AS Rate_Shock,
       f.Shift AS Fx_Shock,
       e.Shift AS Equity_Shock
FROM   RatesShock   r
CROSS  JOIN FxShock f
CROSS  JOIN EquityShock e;

Wynik to 125 scenariuszy (5×5×5). Dodaj kolejną tabelę z wariantami spreadów kredytowych i masz 625 kombinacji. Nie musisz pisać skomplikowanego generatora w Pythonie; prosty SQL wygeneruje pełną siatkę, którą załadujesz do silnika symulacyjnego. Co ważne: product kartezjański zapewnia pełne pokrycie przestrzeni zmiennych, więc analityk nie przeoczy żadnego potencjalnie toksycznego połączenia spadku stóp i osłabienia waluty. Tak właśnie buduje się fundamenty modelu Value at Risk i Expected Shortfall – algoritmy iterują po każdej kombinacji, a silnik SQL dba o dostarczenie danych bez duplikatów i pustych wartości.

---

Case study: stress-testing portfela kredytowego

Zamiast omawiać teorię, przejdźmy do konkretów. Wyobraź sobie bank detaliczny z portfelem 1 000 000 hipotek. Regulator wymaga, by raz w roku przeprowadzić comprehensive stress test pokazujący, co stanie się z kapitałem Tier 1 w trzech makro-scenariuszach: Baseline, Adverse oraz Severe. Na dodatek każdy scenariusz obejmuje trzy poziomy bezrobocia (Low, Medium, High) i dwa warianty inflacji (Steady, Spike). Jak to zaimplementować w bazie?

Najpierw tworzysz tabelę LoanBook (1 000 000 wierszy). Następnie ScenarioSet z 18 rekordami (3×3×2). CROSS JOIN zwraca 18 000 000 wierszy – sporo, ale przy kolumnowym magazynie danych i segmentacji partycji (np. po scenariuszu) operacja trwa minuty, nie godziny. Dzięki temu każdy kredyt otrzymuje zestaw 18 parametryzowanych projekcji, a model LGD (Loss Given Default) może w kolejnym kroku obliczyć stratę w różnych warunkach.

Konstrukcja macierzy kontrahent × scenariusz

Klucz tkwi w tym, by przed CROSS JOIN-em ograniczyć zbiory do absolutnego minimum potrzebnego w symulacji. Zanim dołączysz hipotekę, odfiltrowujesz kredyty spłacone, wyzerowane lub pozostające poniżej progu materialności. Następnie z ScenarioSet wyrzucasz kombinacje, które regulator uznał za nieistotne (np. para Baseline + High unemployment). Pozornie drobiazg, a zmniejsza liczbę wierszy o kilka milionów.

CROSS JOIN:

SELECT l.Loan_ID,
       s.Scenario_ID,
       l.Outstanding_Balance,
       s.Unemployment,
       s.CPI,
       s.Base_Rate
FROM   LoanBook    l
CROSS  JOIN ScenarioSet s;

Rezultat ląduje w tabeli roboczej LoanScenarioGrid. Nad nią odpalasz procedurę, która liczy PD (Probability of Default) w zależności od CPI i bezrobocia, a LGD w zależności od bazowej stopy procentowej. W ostatnim etapie agregujesz straty na poziomie całego portfela i porównujesz z kapitałem regulacyjnym. Właśnie udowodniłeś, że 18 milionów wierszy to nie fanaberia, lecz wymóg metodologii Basel III.

Interpretacja wyników

Po crunchu danych dostajesz macierz Exposure at Default i Expected Loss dla każdej kombinacji parametrów makro. Zauważasz, że w wariancie Severe + High unemployment + Spike inflation łączna strata przekracza 15 % kapitału Tier 1. Wyciągasz wnioski: potrzebny jest bufor, zmiana cen kredytu lub hedging stóp procentowych. Cały ten proces byłby niemożliwy, gdybyś w Excelu ręcznie próbował „powielić” milion pozycji razy 18 wariantów. CROSS JOIN to fundament – jeden operator tworzy siatkę, a reszta to już czysta analityka.

---

CROSS JOIN a raporty BI: grand totals i pivoty

Nie tylko risk manager skorzysta na produkcie kartezjańskim. Dzisiejsze narzędzia BI – Power BI, Tableau, Looker – chętnie pobierają surową siatkę wymiarów, by potem dynamicznie budować pivoty w pamięci. Załóżmy, że analityk controllingu chce zobaczyć marżę na podziale (Produkt × Kraj × Kanał sprzedaży) z automatycznymi „Grand Total” w obu kierunkach. Jeśli wczyta do modelu trzy osobne tabele wymiarów i fakty zliczone tylko tam, gdzie wystąpiła sprzedaż, w macierzy powstaną dziury. Niektóre kraje nie mają pełnego asortymentu, a kanał Online nie istnieje w pięciu rynkach. Raport pokaże zera, a sumy kolumn nie złożą się z sum wierszy.

Rozwiązaniem jest wymuszone rozmnożenie wymiarów. Przygotuj w SQL:

SELECT p.Product_ID,
       c.Country_ID,
       ch.Channel_ID
FROM   DimProduct p
CROSS  JOIN DimCountry c
CROSS  JOIN DimChannel ch;

Model BI dostaje pełną siatkę (np. 100 × 20 × 3 = 6 000 wierszy). Później wystarczy dodać fakt sprzedaży i zastosować LEFT JOIN – pusty wiersz zamieni się w NULL, ale pivot nadal pokazuje sumy. Użytkownik menedżerski widzi spójny raport – każdy kraj, każdy produkt, każdy kanał – nawet jeśli realnie brak transakcji. Bez produktu kartezjańskiego musiałby ręcznie dorzucać brakujące kombinacje, a tabele rosłyby w chaotyczny sposób.

---

Optymalizacja zapytań tworzących duże zbiory

Iloczyn kartezjański ma ciemną stronę – potrafi zjeść RAM, CPU i dyski SSD w mgnieniu oka. Tomek z DBA nie bez powodu denerwuje się, gdy widzi w logach CROSS JOIN bez filtra. Kluczem jest świadoma kontrola rozmiaru oraz harmonogram ETL, żeby potężne siatki powstawały poza godzinami szczytu.

Indeksy hashowane i segmentacja pamięci

Silniki takie jak SQL Server czy PostgreSQL tworzą plan zapytania oparty na operacji Hash Match lub Nested Loops. Przy CROSS JOIN-ie w praktyce dominuje ten pierwszy, bo ma złożoność O(n). Jeżeli wiesz, że generowana siatka jest tymczasowa, możesz wymusić tablicę tymczasową z optymalnym klastrowanym indeksem hashowym na kolumnie ID wymiaru. Pozwoli to szybciej łączyć z faktami i zmniejszy ryzyko spill na dysk.

Kolejny trik to segmentacja. Zamiast tworzyć jedną monstrualną tabelę 5 mld wierszy, partycjonujesz ją po kluczu scenariusza i ładujesz segmentami. Dzięki temu zapytania wykonujące SELECT ... WHERE Scenario_ID = 12 skanują tylko ułamek danych, a nie całą planetę 😉

Limitowanie strumienia danych

Czasem SQL potrzebuje jedynie próbki, by wyestymować plan wykonania – wystarczy dopisać OPTION (FAST 1) w SQL Server albo LIMIT w PostgreSQL, by silnik szybciej wygenerował plan i nie błądził w eksploracji drzewka joinów. Inną praktyką jest przerzucenie ciężaru na CTE z TOP (100000) i późniejsze iteracyjne dokładanie kolejnych bloków danych. Tak powstaje progressive ETL: siatka buduje się w kawałkach, a silnik utrzymuje stały poziom zużycia pamięci. W przypadku hurtowni kolumnowych (Snowflake, BigQuery) można sięgnąć po taski i ławicę workerów, które równolegle przerobią eventy, a wyniki zmaterializują w tablicach klastrowanych.

---

Alternatywne techniki łączenia danych

CROSS JOIN nie jest jedynym sposobem na kompletne połączenie zbiorów. Czasem potrzebujesz podobnej funkcji, lecz bez eksplozji wierszy. Warto znać narzędzia, które oferują podobną elastyczność, a przy okazji pozwalają SQL-owi korzystać z statystyk kardynalności czy filtrować na bieżąco.

OUTER APPLY / CROSS APPLY

W świecie SQL Server i Azure Synapse operator APPLY jest jak szwajcarski scyzoryk: pozwala wykonywać podzapytania korelujące się z każdym wierszem tabeli zewnętrznej. CROSS APPLY przypomina CROSS JOIN, ale działa na wynikach funkcji tabelarycznej. Wyobraź sobie funkcję fn_Get_Monthly_Cashflows(Loan_ID), która generuje harmonogram spłat. W zamiast dublować całą tabelę loanów z kalendarzem, używasz:

SELECT l.Loan_ID,
       c.Pay_Date,
       c.Cashflow
FROM   LoanBook l
CROSS  APPLY fn_Get_Monthly_Cashflows(l.Loan_ID) c;

Silnik uruchomi funkcję tylko dla potrzebnych kredytów, a wynik nie eksploduje do rozmiarów pełnego produktu kartezjańskiego. Jeśli dołożysz OUTER APPLY, zyskasz analogię do LEFT JOIN – dostaniesz także te loany, które dziś nie zwracają cash flow (np. spłacone).

Generatory liczb i Common Table Expressions

Kiedy potrzebujesz siatki dat czy identyfikatorów bez utrzymywania ciężkiej tabeli wymiarów, sięgnij po CTE z rekurencją lub generator liczb systemowych. W PostgreSQL:

WITH RECURSIVE cal AS (
  SELECT '2025-01-01'::date AS d
  UNION ALL
  SELECT d + INTERVAL '1 day'
  FROM   cal
  WHERE  d < '2025-12-31'
)
SELECT *
FROM   cal;

W Snowflake zrobisz to samo jedną linijką: SELECT DATEADD(day, seq4(), '2025-01-01') AS d FROM TABLE(GENERATOR(ROWCOUNT => 365)); Podobną sztuczkę zastosujesz w BigQuery z funkcją GENERATE_DATE_ARRAY. Potem cross-joinujesz wynik z wymiarem produktów i masz kalendarz × towar bez trzymania tysięcy pustych wierszy w trwałej tabeli.

---

Ryzyka: eksplozja wierszy i koszty obliczeń

Żaden inny operator SQL nie potrafi tak spektakularnie wysadzić serwera jak CROSS JOIN. Wystarczy chwila nieuwagi, by z drobnych, kilkuset­wierszowych tabelek powstał potwór zajmujący gigabajty RAM-u i miliony stron pliku wymiany. Dla zespołów finansowych, które liczą każdy milisekundę opóźnienia w nocnym oknie ETL, to ryzyko krytyczne. Wyobraź sobie portfolio 200 tys. kontraktów x 730 dni prognozy x 125 scenariuszy stopy procentowej – to już 18 mld wierszy, a przecież dojdą kolumny walidacyjne, ładowanie do kostki OLAP i backup. Jeśli nie wdrożysz limitów, eksplozja wierszy prędko przerodzi się w eksplozję budżetu chmury lub gniew administratora.

Gdzie najczęściej dochodzi do katastrofy?

Ryzyko	Objawy	Skutek
Nieświadomy CROSS JOIN (brak WHERE)	zapytanie zwraca 10× więcej wierszy niż zwykle	blokada sesji, timeout, awaria raportu
Eksplozja wymiarów w hurtowni	znikają „puste” agregaty, BI zaczyna sumować NULL-e	niespójne KPI, błąd audytorski
Zbyt duży plik tymczasowy	TempDB lub staging S3 puchnie do terabajta	awaryjne czyszczenie, utrata cache
Nieoptymalne sortowanie	sort spill na dysk	wzrost czasu zapytania x 50

Jak się bronić?

1. Próg ostrzegawczy – wstaw IF @@ROWCOUNT > 1e8 RAISERROR(...).
2. Filtrowanie pre-join – push down predicate: ogranicz tabele zanim je rozmnożysz.
3. Partycje & klastrowanie – generuj siatkę kawałkami (po dacie, scenariuszu, regionie).
4. Ograniczenie kolumn – w stagingu trzymaj tylko to, co potrzebne modelowi ryzyka; komentarze i metadane dołączysz później.
5. Próby na kopii – każde nowe zapytanie testuj na środowisku sandbox z limitem wierszy.

---

Iloczyn kartezjański w językach analitycznych (Python, R)

SQL nie jest jedynym miejscem, gdzie włącza się tryb „każdy z każdym”. W Pythonie i R produkt kartezjański to funkcja na jedno wywołanie:

Python / pandas

import pandas as pd

df_rates = pd.DataFrame({'shift_bp': [-200,-100,0,100,200]})
df_fx    = pd.DataFrame({'shift_pct': [-0.2,-0.1,0,0.1,0.2]})

grid = df_rates.merge(df_fx, how='cross')

merge(how='cross') pojawiło się w pandas 1.2 – i natychmiast trafiło na listę hitów w finansach ilościowych. Bez sztuczek z np.repeat i np.tile dostajesz elegancki DataFrame, gotowy do rzutowania na model Monte Carlo.

R / tidyverse

library(tidyr)
grid <- crossing(rates = c(-200,-100,0,100,200),
                 fx    = c(-0.2,-0.1,0,0.1,0.2))

Funkcja crossing() z tidyr jest leniwa bo tworzy ramkę wszystkich kombinacji, zachowując kolejność i atrybuty kolumn. Idealna do scenario analysis: podajesz wektor obligacji, wektor kuponów, wektor terminów i w jednym kroku tworzysz macierz ceny/ryzyka.

Kiedy użyć narzędzi językowych zamiast SQL?

• Twój back-test potrzebuje macierzy w RAM-ie, by wywołać pakiet numeryczny (NumPy, TensorFlow, Stan).
• Chcesz szybko zwizualizować siatkę (ggplot, seaborn heatmap) bez round-tripów do bazy.
• Skalę liczysz w milionach, nie miliardach – wtedy lokalny laptop plus PyArrow załatwi temat.

---

Perspektywa chmurowa: BigQuery, Snowflake, Azure Synapse

Przenosząc hurtownię do chmury, odkrywasz, że kartezjański produkt zmienia barwy niczym kameleon. W SaaS-owych silnikach MPP limit nie jest już RAM-em pojedynczej maszyny, lecz… portfelem.

• BigQuery liczy za processed bytes. CROSS JOIN pustych kolumn kosztuje grosze, ale CROSS JOIN pięciu DECIMAL(38,10) razy miliard? Kilka (-naście) dolarów, i to za jedno zapytanie. Ratunek: klauzula CREATE TABLE ... PARTITION BY, a potem materializacja siatek w nocnych zadaniach.
• Snowflake ma skalę „warehouse’a”. Jeśli puścisz zapytanie na XS, zginie w kolejce. Na L-ce przeleci w minutę, ale zapłacisz kilkanaście kredytów. Dobrym wzorcem jest task chaining: najpierw partycjonujesz siatkę po dacie, potem łączysz w widoku.
• Azure Synapse korzysta z rozproszonego ROUND_ROBIN lub klucza hash. Jeżeli zapomnisz o DISTRIBUTION = HASH(Scenario_ID), data-shuffling przy CROSS JOIN-ie zabije throughput. Pamiętaj też o RESOURCE_CLASS smallrc dla developera – ograniczy rozrzut kosztów testów.

W każdym z tych środowisk obowiązują dwa dogmaty: usunąć puste kolumny i zmaterializować duże siatki zamiast liczyć je ad-hoc. W przeciwnym razie rachunek za chmurę przekroczy wartość niejednego hedgingu.

---

Przyszłość łączenia danych: iloczyn kartezjański, a semantyka grafowa

Czy produkt kartezjański ma jeszcze sens w erze grafów i lakehouse’ów? Jak najbardziej – ale zmienia funkcję. W modelach grafowych (Neo4j, TigerGraph) JOIN dostaje interpretację semantyczną: węzeł × węzeł = krawędź. Tymczasem w SQL wciąż generujesz pełną siatkę i później filtrujesz.

Przykład: budujesz knowledge graph klientów, kontraktów i ryzyka. Zamiast trzymać tabelę portfela 10 mld wierszy, zapisujesz węzły Client, Loan, Scenario i tworzysz krawędzie OWNS, TESTED_UNDER. Iloczyn kartezjański przechodzi do etapu ładowania grafu: w loaderze SQL tworzysz siatkę Loan × Scenario i zamieniasz każdy wiersz na krawędź. Po migracji eksplozję wierszy przejmie silnik grafowy, który potrafi leniwie rozwijać relacje w trajektorii zapytania (pattern matching).

W świecie data-fabric coraz więcej firm buduje warstwę wirtualną, w której JOIN-y realizuje na żądanie Federated Engine. Produkt kartezjański staje się kamieniem milowym: tam, gdzie kombinacje są logicznie potrzebne (np. kalendarz × region), materializujesz; gdzie zaś zależy Ci na semantycznych relacjach, delegujesz do grafu. To hybrydowe podejście zmniejsza koszty i skraca czas eksploracji danych.

---

Podsumowanie i najważniejsze wnioski

Iloczyn kartezjański to nic innego jak maksymalna kompletność – wszystkie pary, wszystkie kombinacje, zero luk. W matematyce tworzy przestrzeń punktów; w SQL-u – tabele milionów wierszy; w finansach – macierze scenariuszy, bez których ryzyko pozostaje czarną skrzynką. Kluczowy jest kontekst:

1. Kiedy potrzebujesz pełni – stress-test, VaR, kalendarz wymiarów – sięgaj śmiało po CROSS JOIN lub merge(how='cross').
2. Kiedy zależy Ci na szybkości – filtruj przed joinem, partycjonuj, używaj APPLY albo wygeneruj siatkę w mniejszych porcjach.
3. Chmura zmienia rachunek – kosztu nie liczy już DBA, tylko karta kredytowa. Monitoruj bajty, nie tylko wiersze.
4. Grafy nie zabijają kartezjańskiego produktu; raczej przenoszą go na poziom ETL i uzupełniają semantyczną warstwą „rozsądku”, która odsiewa puste krawędzie.

Jeśli nauczysz się używać CROSS JOIN-a jak skalpela, a nie młota, zyskasz przewagę zarówno w SQL-u, jak i Pythonie, a Twój zespół ryzyka policzy więcej scenariuszy w mniej czasu – i to bez dreszczy na widok rachunku z chmury.

---

Podsumowanie i najważniejsze wnioski

Finansowe i analityczne życie danych — o ile traktowane jest poważnie — rządzi się dwoma przeciwstawnymi prawami. Pierwsze mówi: „zebrane informacje mają sens tylko wtedy, gdy potrafimy zestawić ze sobą wszystkie elementy układanki”. Drugie ostrzega: „każde niepotrzebne łączenie kosztuje – najpierw czas, potem zasoby, w końcu pieniądze”. Iloczyn kartezjański to perfekcyjne skrzyżowanie tych praw. Z matematycznego punktu widzenia gwarantuje on kompletność: żadna para (lub trójka, czwórka …) elementów nie pozostaje pominięta. Dzięki temu analityk ryzyka może spać spokojnie, wiedząc, że w stres-teście portfela hipoteki trafiły zarówno na scenariusz recesji, jak i inflacyjnego boomu. Z drugiej strony ta sama kompletność, użyta bez umiaru, materializuje się pod postacią miliardów wierszy, zapełnionych dysków, spirali kosztów chmurowych i nocnych telefonów od DBA-ów z pytaniem, „kto znowu puścił CROSS JOIN bez filtra”.

Klucz leży w trzech praktykach, do których warto wracać przy każdym projekcie data-riskowym. Po pierwsze minimalizacja przed mnożeniem: filtruj, deduplikuj i przycinaj tabele do absolutnego minimum, zanim w ogóle pomyślisz o CROSS JOIN-ie. Po drugie partycjonowanie wyników: jeśli pełna siatka jest niezbędna, ładuj ją partiami — podziel scenariusze na paczki, a kalendarz na kwartały. Zyskasz płynny ETL i mniejszy szczytowy pobór pamięci. Po trzecie materializacja tylko raz: produkty kartezjańskie, które stanowią stałą bazę (np. kalendarz × typ dnia), warto zmaterializować do osobnej tabeli wymiarów i odwoływać się do niej przez lekkie widoki, zamiast tworzyć ją ad hoc w każdym raporcie.

W erze lakehouse’ów, grafowych silników i federacyjnych warstw semantycznych iloczyn kartezjański nie odchodzi do lamusa – wręcz przeciwnie, staje się fundamentem, na którym te nowinki operują. Różnica polega na tym, że dziś mamy znacznie więcej narzędzi, by ujarzmić jego wściekły wzrost wykładniczy: magazyny kolumnowe SUPRL, selektywne klastrowanie, lazy-evaluation w Pandas, czy wreszcie kompresję w Snowflake i BigQuery. Gdy dodać do tego sprawną kontrolę kosztów (pragmatyczne cost-based optimizery), iloczyn kartezjański staje się nie zagrożeniem, lecz przewagą konkurencyjną. Bo ten, kto potrafi w jednym przebiegu przetestować każdy możliwy scenariusz, szybciej wyłapie nadciągające ryzyko i dokładniej wyceni wartość chronioną kapitałem.

Ostatecznie więc recepta brzmi: mierz, gdy naprawdę musisz; licz, gdy wiesz, że Cię stać; łącz, gdy każde połączenie wnosi informacje, a nie tylko bity. Wtedy CROSS JOIN z narzędzia destrukcji zamieni się w most między surową dżunglą danych a uporządkowanym krajobrazem decyzji finansowych.

---

FAQ – Najczęściej zadawane pytania

1. Czy istnieje „bezpieczny” limit wierszy dla CROSS JOIN-a?
Nie ma jednego magicznego progu, bo wszystko zależy od mocy klastra lub warehouse’a, kompresji kolumn, a nawet pory dnia w oknie ETL. W praktyce analitycy ustawiają miękkie alerty – np. 100 mln wierszy w środowisku on-prem albo 5 TB danych przetworzonych w BigQuery – a powyżej tych wartości każą zapytaniu przechodzić przegląd architekta.

2. Jak zamienić niechciany iloczyn kartezjański w join warunkowy, nie przepisując całego SQL-a?
Najszybciej dodać warunek w klauzuli ON lub WHERE, który ograniczy łączenie do logicznych par. Przykład: FROM Products p CROSS JOIN Prices pr WHERE p.id = pr.product_id AND pr.valid_on = '2025-12-31'. W praktyce to już nie jest „czysty” iloczyn, lecz klasyczny INNER JOIN – ale wystarczy, by zredukować eksplozję wierszy.

3. Czy Pandas merge(how='cross') jest szybszy od SQL-owego CROSS JOIN-a?
Dla zbiorów rzędu kilkudziesięciu tysięcy wierszy – zwykle tak, ponieważ operuje bezpośrednio w pamięci i korzysta z natywnych wektorowych operacji NumPy. Powyżej kilkuset tysięcy wierszy lepiej przekazać ciężar na silnik kolumnowy, który rozproszy pracę na wiele węzłów i zminimalizuje kopiowanie danych.

4. W chmurze kosztuje mnie każdy bajt przetworzony w CROSS JOIN-ie. Jak najprościej zbić rachunek?
Najbardziej „budżetowym” sposobem jest selektywne pobieranie kolumn, których naprawdę potrzebujesz do dalszych obliczeń, oraz wcześniejsza kompresja lub castowanie precyzyjnych DECIMAL(38,10) na FLOAT. W Snowflake warto też uruchomić warehouse w rozmiarze S lub M na czas generowania siatki, a potem zamykać go, by nie płacić za bezczynność.

5. Czy iloczyn kartezjański ma sens w bazach grafowych, gdzie relacje są z natury selektywne?
Tak, ale na innym etapie. W loaderze grafu często generuje się pełną siatkę „węzeł × scenariusz” i zapisuje ją w postaci krawędzi. Później, podczas zapytań, silnik grafowy rozwinie relacje tylko wtedy, gdy dopasowanie wzorca faktycznie ich wymaga, dzięki czemu unika eksplozji węzłów w operacjach on-line.

---