LIMIT 350,20? A może coś innego? Opcje

[msulik]

Wstęp: Napisałem skrypt do wyszukiwania w bazie danych. Skrypt ten umożliwia zaawansowane wyszukiwanie rekordów według kilku skomplikowanych kryteriów. Spodziewam się, że dość szybko ta baza osiągnie ponad tysiąc wpisów.

Problem: Przypuśćmy, że ktoś wpisał do bazy zapytanie, które zawiera zaawansowane opcje wyszukiwania włączając w to zagnieżdżone nawiasy, operatory logiczne itp. Zapytanie to zwróciło okolo 500 rekordów. Jasną rzeczą jest, że nie wypiszę tych wszystkich 500 wyników na jednej stronie, tylko powiedzmy w porcjach po 20.

Pytanie: Jak zrobić, żeby porcjować te wyniki bez ponownego wysyłania zapytania. Tzn. nie chcę stosować, powiedzmy,

Kod

SELECT * FROM moja_tabela WHERE (pole = 'abc' AND ...................) LIMIT 350, 20

bo to powoduje ponowne przetworzenie zapytania (co zajmuje czas!), a następnie obcięcie go do zaledwie 20 wyników. Jak to zrobić? Czy wysyłać cookie z numerami wyników, czy może przekazywać parametry w url'u, czy ewentualnie "spakować" te numery?

Rozwiązanie przez cookie albo url wydają się być nierealne, zważywszy na ilość potencjalnych rekordów do zwrócenia (przy 1000 wynikach rozmiar ten wyniesie około 3000 bajtów, co zniechęci do dalszych poszukiwań).

[GeoS]

http://webdeveloper.pl/html/news/2001/04/21/121.php :-)

[msulik]

Thx za link, ale...

Przeczytałem od deski do deski i nie znalazłem odpowiedzi na moje pytanie.

Chodzi mi o to, że nie chcę używać LIMIT, bo zapytanie może być skomplikowane i wtedy za każdym wywołaniem SELECT * FROM .... LIMIT ..,.. zapytanie to jest od nowa przetwarzane. A ja właśnie nie chcę, żeby było przetwarzane od nowa, bo to nie ma sensu.

[GeoS]

To ja innego rozwiazania niestety nie widze :-(

Niby jak to by miało wyglądać? Nie da sie sprawdzic, od którego wiersza miałoby zwracać wyniki i ile tych wierszy miałoby być pobieranych, w inny sposob niz z LIMITem.

Ja innej koncepcji nie mam :-(

[GeoS]

Warto tez pomyslec nad aplikacja cache'ujaca :-) To czesciowo rozwiazaloby twoj problem.
Jest kilka aplikacji (soft na serwer, a nie skrypty php) dostepnych za free :-)

[msulik]

Warto tez pomyslec nad aplikacja cache'ujaca :-)

tego się obawiałem...

czesciowo rozwiazaloby twoj problem

a tego jeszcze bardziej się obawiałem...

soft na serwer, a nie skrypty php

a o tym to nawet nie śniłem w najgorszych koszmarach...


Cóż, będę musiał zmusić mój mózg do poszukiwania dalszych rozwiązań. Thx.

[carampuc]

Hi, Man!

Tak na szybko.
Załóż sobie tabelkę, która będzie miała takie pola jak te zwracane w zapytaniu wyszukującym + pole z id sesji użytkownika.
Druga tabelka będzie miała dwa pola: id sesji + treść zapytania.
Jeśli użuytkownik uruchomi wyszukiwanie po pierwsze w drugiej tabelce spradź, czy zapytanie to nie było już wcześniej wykonywane. Jeśli nie, wykonaj to zapytanie PEŁNE (bez LIMIT) i jego wynik (rekordy) wpisz do tabelki 1, dodając id sesji.
Po tym, lub też jeśli zapytanie już było, odczytaj odpowiednio dane z tabelki 1 dla właściwego id sesji.
To tak na szybko i ogólnie.
Powodzenia.

[carampuc]

POST SCRIPTUM:
Oczywiście co jakiś czas musisz czyścić obie tabele z nieaktualnych już id sesji...
:oops:

[GeoS]

Tylko nalezaloby przeprowadzic testy, na ile rozwiazanie z nowymi tabelami rzeczywiscie zoptymalizowaloby dzialanie calej aplikacji.
Moze sie okazac, ze bedzie duzo mniej wydajne, anizeli inne przedstawione sposoby.

[kryr]

Na zdrowy rozum, to powinno byc szybciej... Choc na pewno nie wtedy, gdy bedzie sie "odswiezac bufor" - ta 2 tabelke ze sesja...

[carampuc]

2 tabelka służy ona tylko temu, aby sparawdzić, czy korzystamy z tego samego zapytania. Jeśłi nie zmienimy zapytania (wybieranych danych) - czyli np/zmieniamy stronę - zysk będzie duży? Jeśli zmienimy zapytanie spowolnienie będzie niezauważalne.

Nie upieram się, że jest to rozwiązanie "genialne i najlepsze na świecie", ale czasami zapytania wybierające dane są na tyle skomplikowane i czasochłonne, że warto zastanowić się nad takimi patentami.
Chociaż z mojego doświadczenia wynika, że w 98% przypadków wystarczy dobrze dobrać indeksy - tych nigdy nie za mało i lepiej odżałować na nie trochę miejsca na serwerze.