Mam mały problem z zapytaniem.
Mam tabelki:
board_topic -> id,id_autora_tematu,id_autora_ostaniego_posta
user -> id,name

Nazwy są intuicyjne, mimo tego wyjaśnię:
Pierwsza przechowuje id tematu, id użytkownika który założył temat, i id użytkownika który jako ostatni wypowiedział się w temacie.
Problem pojawia się kiedy chce pobrać 20 rekordów. Wykombinowałem to tak:

[SQL] pobierz, plaintext 
SELECT board_topic.topic ,user.name
FROM board_topic 
LEFT JOIN user ON user.id = board_topic.id_autora_tematu OR  user.id = board_topic.id_autora_ostaniego_posta
LIMIT 20
// wynik
1. Przykładowy temat numer 1 | Michał //autor tematu
2. Przykładowy temat numer 1 | Maciek //autor ostatniego postu
3. Przykładowy temat numer 2 | Monika //autor tematu
4. Przykładowy temat numer 2 | Maciek //autor ostatniego postu
[SQL] pobierz, plaintext 

Jak widać każdy z tematów występuje 2 razy, i jest to zrozumiałe -> tak skonstruowane jest zapytanie.
Jest jakiś inny sposób aby złączyć tabele w sposób: jednemu rekordowi z jednej dołączamy 2 z innej tabeli ?

//----------------------------------------------
Coś nie daję rady z tym SQL dzisiaj
Mam tabele z tematami -> które podzieliłem na kategorię. I chce pobrać po 20 rekordów z każdej.

[SQL] pobierz, plaintext 
SELECT * FROM board_topic WHERE category =`help` LIMIT 20
SELECT * FROM board_topic WHERE category  = `question` LIMIT 20
SELECT * FROM board_topic WHERE category  = `question` LIMIT 20
[SQL] pobierz, plaintext 

Oczywiście mogę to zrobić jak wyżej z 3 SELECT wykorzystując multipleQuery. Ale da się to zrobić lepiej ? optymalniej ? może w 1 zapytaniu ?

http://www.w3schools.com/sql/sql_union.asp

To drugie mamy rozwiązane.

UNION jest też odpwiedzą na 1 problem ? bo jeśli tak to nie mogę załapać. Some tip, please ?

Nie widzę przeszkód by łączyć dwukrotnie do tej samej tabeli (pod innymi aliasami), za pierwszym razem by dostać dane autora, za drugim by dostać dane ostatniego wypowiadającego się w temacie.
Wtedy limit 20 będzie dotyczył pojedyńczych tematów.
Poza tym, jeśli w każdym temacie oba pola są wypełnione (jeśli nikt nie odpowiedział to post startowy traktujemy jako ostatni, więc oba id są identyczne), a użytkownicy nie są kasowani ani nie zmieniają id, to nie jest potrzebny LEFT JOIN, wystarczy zwykły JOIN ( czyli INNER JOIN precyzyjnie ujmując ).

Nie wiedziałem że konstrukcja JOIN pozwala na takie coś. W kursach nigdy się z takim czymś nie spotkałem.

Dla podsumowania wklejam ostateczne zapytanie. Jakby ktoś miał jeszcze jakąś sugestię pozwalającą to ulepszyć to proszę bardzo.

[SQL] pobierz, plaintext 
SELECT board_topic.topic ,start.name,last.name
FROM board_topic 
JOIN user AS start ON start.id = board_topic.id_autora_tematu 
JOIN user AS last ON  last.id = board_topic.id_autora_ostaniego_posta
category =`help`
LIMIT 20
UNION
SELECT board_topic.topic ,start.name,last.name
FROM board_topic 
JOIN user AS start ON start.id = board_topic.id_autora_tematu 
JOIN user AS last ON  last.id = board_topic.id_autora_ostaniego_posta
category =`question`
LIMIT 20
[SQL] pobierz, plaintext 

a tak może być

[SQL] pobierz, plaintext 
SELECT board_topic.topic ,start.name,last.name
FROM board_topic
JOIN user AS start ON start.id = board_topic.id_autora_tematu
LEFT JOIN user AS last ON last.id = board_topic.id_autora_ostaniego_posta
WHERE
category =`help` OR category =`question`
LIMIT 20
[SQL] pobierz, plaintext 

bpskiba nie może tak być.
Ja chce pobrać po 20 z każdek kategorii. 20 z help i 20 z question.
/--------
Dodam tylko że jestem świadomy innego rozwiązania:
W oryginalnym skrypcie oczywiście znajduje się jeszcze jedna tabela:

[SQL] pobierz, plaintext 
Board_post -> id_postu, id_tematu, id_autora, id_data_postu
[SQL] pobierz, plaintext 

Można by w tabeli board_topic zamiast id_autorów przechowywać id_pierwszego postu oraz id_ostatniego postu. I JOIN’nować koleją tabelę -> board_post. W takiej sytuacji nie dublowałbym tych samych danych (id_autorów, datę_postów).
Wolę świadomie zwiększyć wielkość bazy danych niż obciążać ją bardziej złożonymi zapytaniami. To rozwiązanie wydaje się optymalniejsze, jeżeli się mylę proszę o odpowiedź.