Dit is een manier om het resultaat te krijgen.
Deze benadering maakt gebruik van gecorreleerde subquery's. Elke subquery gebruikt een ORDER BY clausule om de gerelateerde rijen uit tabel 2 te sorteren en gebruikt de LIMIT clausule om de 1e, 2e en 3e rij op te halen.
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
VERVOLG
@gliese581g wijst erop dat er prestatieproblemen kunnen optreden bij deze aanpak, aangezien een groot aantal rijen wordt geretourneerd door de buitenste query, aangezien elke subquery in de SELECT-lijst wordt uitgevoerd voor elke rij die wordt geretourneerd in de buitenste query.
Het spreekt voor zich dat deze aanpak om een index schreeuwt:
ON table2 (PKID_FROM_TABLE_1, U_DATA)
-of, op zijn minst-
ON table2 (PKID_FROM_TABLE_1)
Het is waarschijnlijk dat de laatste index al bestaat, als er een externe sleutel is gedefinieerd. Met de vorige index kan de zoekopdracht volledig worden uitgevoerd vanaf de indexpagina's ("Index gebruiken"), zonder dat een sorteerbewerking nodig is ("Fisor gebruiken").
@glies581g wijst er terecht op dat de uitvoering van deze aanpak problematisch kan zijn op "grote" sets.