Hvordan justeres regnskabssignaler med markedsafkastdata? Et eksempel med SQL-kode

Den vigtigste afhentning: Hvis din tabel har millioner af poster, undgår du på alle måde indlejrede SQL-forespørgsler; Brug i stedet gruppen ved + inner join.

I porteføljesorter befinder vi os lejlighedsvis i følgende situation:

Vi har en returtabel A med overskrifter: | ID | dato | retur |
og en regnskabssignaltabel B med overskrifter: | ID | datadate | signal |
Uden tab af generelitet kan vi antage, at afkast er i månedlig frekvens, og regnskabssignaler er i kvartalsfrekvens. Vi vil gerne konstruere månedlige rebalanserede porteføljer i henhold til, for eksempel, de seneste signaler 1 måned væk. Spørgsmålet opstår: hvordan skal vi flette de to tabeller?

Næsten med det samme kan man tænke på følgende indlejrede underforespørgsel:

Opret tabel fusioneret bord SOM VÆLG a.ID, a.date, a.return, b.datadate, b.signal FRA A som a, B as b WHERE a.ID = b.ID og b.datadate = (SELECT max (datadate ) som datadat FRA B som c HVOR a.ID = c.ID OG intck ('måned', c.datadate, a.date)> = 1);

intck er en SAS-funktion, der returnerer antallet af måneder mellem to datoer. Du kan finde lignende funktioner i andre varianter af SQL.

Hovedidéen er: for hver post i A ønsker vi at finde den seneste post i B, der opfylder kriterierne på mindst 1 måned. Det fungerer til en lille prøve med et par tusinder af observationer, men tiden øges dramatisk, når prøvestørrelsen skalerer op til millioner. Faktisk tager det over en nat at køre koden på en 3-million-post A og en -8-million-record B.

Så hvad er det næste?

Vi kan opdele den indlejrede forespørgsel i en gruppe efter og en intern sammenføjningserklæring:

Opret TABEL fusioneret bord SOM VÆLG a.ID, a.date, a.return, b.datadate, b.signal FRA A som en indre sammenføjning B som b HVOR a.ID = b.ID OG intck ('måned', b. datadate, a.date)> = 1 GRUPPE AF a.ID, a.date HAVING b.datadate = max (b.datadate);

Det reducerer behandlingstiden over en sag på millioner poster til inden for titusinder af sekunder.

Så det er værd at en sammenfattelse, der muligvis sparer times ventetid: brug gruppe ved + inner join i stedet for nestede forespørgsler.