Inteligentne wyszukiwanie z kilku tabel, + stronicowanie Opcje

[Sztef89]

Witam, mam problem z zapytaniem. Chciałbym jednym zapytaniem przeszukać 7 tabel, wyniki posegregować po najbardziej trafnych i ustawić LIMIT x,10. Na razie zrobiłem SELECT'a dla dwóch tabel (bez stronicowania i sortowania wyników):

[SQL] pobierz, plaintext 
SELECT uniqid, tytul, tytul_oryg, rok FROM media_filmdata
WHERE MATCH(tytul,tytul_oryg) AGAINST('słowo szukane' IN BOOLEAN MODE)
UNION ALL
SELECT uniqid, tytul, tytul_oryg, rok FROM media_serialdata
WHERE MATCH(tytul,tytul_oryg) AGAINST('słowo szukane' IN BOOLEAN MODE)
[SQL] pobierz, plaintext 

Jakbym dodał limit na końcu to wyniki z drugiej tabeli by się wcale nie wyświetliły (nawet jakby słowo szukane było trafione w 100%) dlatego chciałbym posortować wyniki od najlepiej pasujących i wtedy dopiero ograniczyć wyświetlanie.

Przeszukałem już sporo stron, i sporo się dowiedziałem ale nie mogę znaleźć rozwiązania na własnie ten problem.
Z góry dzięki !


-- EDIT --

Trochę pokombinowałem i uzyskałem coś takiego:

[SQL] pobierz, plaintext 
SELECT uniqid, tytul, tytul_oryg, rok, MATCH(tytul,tytul_oryg) AGAINST('house') AS score FROM media_filmdata
WHERE MATCH(tytul,tytul_oryg) AGAINST('house')
UNION ALL
SELECT uniqid, tytul, tytul_oryg, rok, MATCH(tytul,tytul_oryg) AGAINST('house') AS score FROM media_serialdata
WHERE MATCH(tytul,tytul_oryg) AGAINST('house')
 
ORDER BY  `score` DESC
[SQL] pobierz, plaintext 

Ale od razu można zauważyć, że score wyników jest zależny od ilości wyników z danej tabeli. Chciałbym każdą tabelę ograniczyć aby nie "przytłumiła" wyników z drugiej tabeli ("sprawiedliwość"). Już prawie jest to co chce uzyskać ale to tylko prawie... :/

Czyli jak zrobić aby waga nie była uzależniona od ilości wyników TYLKO o samej trafności słowa ?

Ten post edytował Sztef89 7.11.2011, 14:30:48

[Sephirus]

1. Przeszukiwanie z użyciem widoku polegałoby na zrobienie widoku z wszystkich 7 tabel, a następnie ten widok należałoby przeszukać metodą MATCH... AGAINST... ?

Dokładnie tak - rekordy w widoku będą traktowane jak z jednej tabeli - musisz jedynie zapewnić jednolitość pól.

2. Nie trzeba robić indeksu do tego widoku aby go przeszukiwać powyższa metodą ?

Index w widoku... hmm... Można - ale powiem szczerze nigdy tego nie robiłem (nie robiłem tak zaawansowanych widoków) - teoretycznie powinien to przyspieszyć.

3. Czy takie rozwiązanie byłoby wydajne ?

Nie całkiem. Dlaczego? To działa podobnie (albo nawet tak samo) jak podzapytania. Może nieco lepiej bo to jednak po stronie serwera się dzieje ale mimo wszystko polega na tym samym. Kwestia dobrania odpowiednich pól (po co wszystkie), pokombinuj z indexem jak wspomniałeś i powinno działać względnie. Musisz też zrozumieć, że takie zapytanie jest samo w sobie bardzo skomplikowane i czasowo i zasobowo.

Czy warto?
Tak. Dlaczego? Nie zrobisz tego inaczej - jeżeli chcesz wyszukiwać w wielu tabelach naraz tak by tabele nie były od siebie zależny ani nie były ustawione w jakiejś kolejności to musisz to wszystko wrzucić do jednego wora. Ten wór najłatwiej zastąpić widokiem - inaczej dałoby się napisać zapytanie szukające po tych tabelach ale byłoby cholernie długie i wydaje mi się - mniej wydajne (IMG:style_emoticons/default/wink.gif)

4. Czy stworzony widok jest tymczasowy czy raz stworzony można używać wiele razy ?

Widok to taka jakby wirtualna tabelka - istnieje w bazie i ma swoją nazwę. W wielu przypadkach można go traktować jak tabelkę (oczywiście tylko odczyt).
Pamiętaj tylko że jak bierzesz select z tabelki to masz z tego rekordy jak bierzez select z widoku to masz najpierw wywołanie zapytania widoku (zebranie rekordów) następnie dopiero z tej puli wykonywany jest select.

5. Co jak zawartości tabel się zmienią (dojdą nowe rekordy) - widok wtedy będzie zawsze "zaktualizowany" ?

Jeśli widok to tak naprawdę grupowanie wyników to jest zawsze aktualny - co prawda są chyba jakieś opcje bardziej zaawansowane ale nigdy ich nie używałem.

A teraz niespodzianka (IMG:style_emoticons/default/wink.gif)

Bo na pewno zastanawiasz się teraz: "Kurde tyle zachodu a i tak nie będzie super wydajne" - owszem - bo ogólnie tego się tak nie robi (IMG:style_emoticons/default/smile.gif)

Nie łączy się tabel z różnymi rzeczami jak się po nich wyszukuje tak po prostu - są do tego specjalne systemy.

A jak się to robi bez systemów - opcje są 2:

1. Można zrobić tabelkę główną z treściami w stylu ID | TYP | ID_WLASCICIELA | TRESC - wówczas masz wszystkie dane dotyczące wszystkiego - typ określa czy to news/post/artykuł itp, ID_WŁAŚCICIELA określa ID elementu do którego treść jest przypisana, no i sama TREŚĆ (IMG:style_emoticons/default/wink.gif)

2. Jeżeli masz wiele rodzajów rzeczy na stronie tak jak u Ciebie widzę seriale i filmy - można również zamiast 1 zapytania (bardzo kombinowanego) obejść problem szybciutko dodając select obok wyszukiwania z wyborem gdzie szukamy - kto powiedział że musi tam się znaleźć opcja "szukaj wszedzie" (IMG:style_emoticons/default/wink.gif)

3. Można zamiast jednego zapytania dać tyle ile mamy rodzaji szukanych elementów i wyświetlić je na przykład tak:

SERIALE:
a
b
c

FILMY:
a
b
c

Te sposoby mogą wydawać się śmieszne ale są wydajne i łatwe w obsłudze (IMG:style_emoticons/default/wink.gif)