Dette er en måde at få resultatet på.
Denne tilgang bruger korrelerede underforespørgsler. Hver underforespørgsel bruger en ORDER BY klausul til at sortere de relaterede rækker fra tabel2, og bruger LIMIT klausul for at hente 1., 2. og 3. række.
SELECT a.PKID
, a.DATA
, (SELECT b1.U_DATA FROM table2 b1
WHERE b1.PKID_FROM_TABLE_1 = a.PKID
ORDER BY b1.U_DATA LIMIT 0,1
) AS U_DATA1
, (SELECT b2.U_DATA FROM table2 b2
WHERE b2.PKID_FROM_TABLE_1 = a.PKID
ORDER BY b2.U_DATA LIMIT 1,1
) AS U_DATA2
, (SELECT b3.U_DATA FROM table2 b3
WHERE b3.PKID_FROM_TABLE_1 = a.PKID
ORDER BY b3.U_DATA LIMIT 2,1
) AS U_DATA3
FROM table1 a
ORDER BY a.PKID
OPFØLGNING
@gliese581g påpeger, at der kan være præstationsproblemer med denne tilgang, med et stort antal rækker, der returneres af den ydre forespørgsel, da hver underforespørgsel i SELECT-listen udføres for hver række, der returneres i den ydre forespørgsel.
Det burde sige sig selv, at denne tilgang råber på et indeks:
ON table2 (PKID_FROM_TABLE_1, U_DATA)
-eller som minimum-
ON table2 (PKID_FROM_TABLE_1)
Det er sandsynligt, at sidstnævnte indeks allerede eksisterer, hvis der er defineret en fremmednøgle. Det tidligere indeks ville gøre det muligt for forespørgslen at blive tilfredsstillet helt fra indekssiderne ("Brug af indeks") uden behov for en sorteringsoperation ("Brug af filersortering").
@glies581g har helt ret i at påpege, at udførelsen af denne tilgang kan være problematisk på "store" sæt.