To jeden ze sposobów uzyskania wyniku.
To podejście wykorzystuje skorelowane podzapytania. Każde podzapytanie używa ORDER BY klauzula, aby posortować powiązane wiersze z tabeli2 i używa LIMIT klauzula do pobrania pierwszego, drugiego i trzeciego wiersza.
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
KONTYNUACJA
@gliese581g wskazuje, że przy takim podejściu mogą wystąpić problemy z wydajnością, z dużą liczbą wierszy zwracanych przez zapytanie zewnętrzne, ponieważ każde podzapytanie z listy SELECT jest wykonywane dla każdego wiersza zwróconego w zapytaniu zewnętrznym.
Nie trzeba dodawać, że takie podejście wymaga indeksu:
ON table2 (PKID_FROM_TABLE_1, U_DATA)
-lub przynajmniej-
ON table2 (PKID_FROM_TABLE_1)
Prawdopodobnie ten drugi indeks już istnieje, jeśli zdefiniowano klucz obcy. Poprzedni indeks umożliwiałby pełne zaspokojenie zapytania ze stron indeksu ("Korzystanie z indeksu"), bez potrzeby operacji sortowania ("Korzystanie z sortowania plików").
@glies581g ma rację, wskazując, że wydajność tego podejścia może być problematyczna w przypadku „dużych” zestawów.
