Jump to content
php.lv forumi

Meklēšanas rezultātu dalīsana lapās


john.brown

Recommended Posts

Tātad, tiek veikta mekl�“sana dažādu moduļu tabulās. Rezultāti pagaidām likti iekš masīva, tipa

$finder = new SearchFinder(); // inicializ�“jam mekl�“tāja objektu
$finder->setSearchString($_GET['search']);

while($modules) { // ejam cauri visiem moduļiem
$mod = array_shift($modules);
$cfgfile = $mod[0].'config/searchrules.php';
if(!is_file($cfgfile)) continue;
include($cfgfile); // dabonam kādās tabulās, p�“c kādiem laukiem meklet

$finder->setSearchRules($rules); // $rules - masīvs nodefin�“ts ieks $cfgfile
$results = $finder->doSearch();	

 // pievienojam svaigi atrastos ierakstus iepriekš atrastajiem	
$this->viewArgs['results'] = array_merge($this->viewArgs['results'],$results);
}

Tāds variants, saprotams rada probl�“mas ar dalīšanu lapās, ja ierakstu daudz. Domas, kā atrisināt ir sekojošas.

 

Veidot tabulu search_results, kurā likt iekša rezultātus, tad no tās taisīt selectu ar limit, p�“c kam dz�“st visu mekl�“šanas rezultātu. Nepatīk, ka katru reizi, pieprasot nākamo lapu, pa jaunu jāmekl�“ cauri visām tabulām. Vai arī likt iekšā kādu timestamp, un katru reizi dz�“st ierakstus, kas vecāki par kādu laiku... V�“l ir doma, izmantot heap tabulu...

 

Ar vien vārd sakot, kādas var�“tu būt idejas efektīvam risinājumam?

 

P.S. vēl ienāca prātā, varbūt tos rezulttus vispār nelikt iekš db, bet ielikt kā masīvu iekš sessijas? Un tad taisīt slici no šamiem... Tas atbrīvotu no nepieciešamības tīrīt vairs nevajadzīgos...

Edited by john.brown
Link to comment
Share on other sites

Parastam selectam ar limitu nav ne vainas, ja tas būtu viens selekts. Tak tas rezult�“jošais masīvs ir vairāku selectu rezultāts. To biš, mekl�“šanai katrā modulī ir savs selekts, jo katram modulim ir savas k. kādas tabulas, ar saviem laukiem, kuros meklet... Nesanāk nekādi parasts ar limitu :)

 

Jeb tu no kurienes domāji to "katru reizi"?

 

----------------------

Uz lietu neattiecas, tak pēc Quick Edit forumā garais e paliek par jautājumzīmi ar pēdiņu. IMHO, kaut kur jānomaina str_replace() uz mb_ereg_replace()... vismaz man iekš RTE kādreiz līdzēja.

Edited by john.brown
Link to comment
Share on other sites

Laikam gan nesanāks apvienot. Moduļi visi ir praktiski neatkarīgi, katram ir k. kādi savi meklēšanas ruļļi. Apvienošana/procedūras radīs imho lieku savstarpējo atkarību visai tai lietai, un pats process bik hemorojiska būs. Vot meklēšanas rezultāti visiem moduļiem ir pilnīgi vienā formātā, un tos mierīgi varētu likt kādā temp tabulā. Un no turienes jau taisīt to limit. Jautājums, kā efektīvi šamo tīrīt... Vai sessijā likt. Tad vispār tīrīšanas jautājums atkrīt...

Link to comment
Share on other sites

ja nav svarīgi zināt ierakstu skaitu (un līdz ar to lapu skaitu) tad var selektot ar LIMITU tjip pagelimit+1.. respektīvi tu zināsi, ka ir vairāk par piemēram 20 ierakstiem (vienas lapas limits), ja atselektēsies 21 ieraksts... un tad jau tikai atliek pielikt <-bck ffwd-> :)

Link to comment
Share on other sites

Nu, tas atkal ir viena selecta risinājums... Vai jāuzskaita procesā, cik jau ir rezultāti atrasti, un izejot no tā dinamiski jāmaina LMIT parametri nākamajam. Un atkal ejot pa fwd-> jātaisa viltīgs algoritms, lai sāktu no vietas, kur iepriekšējā lapa beidzās. Hemorojs...

Patiesībā jau nolēmu sessijā glabāt. Datu apjoms orientējoši nesanāk pārāk liels...

 

Tak turpinājumā vēl jautājums. Vai var dabūt no db ārā "sakritību skaitu"? Tipa selects ar WHERE field LIKE '%bla%' - cik reižu katrā ierakstā tas bla ir atrasts. Jeb to var tikai ar kādu substr_count() dabūtajam textam izdarīt?

Link to comment
Share on other sites

kur kāds gemarojs?

viss normāli tak. SELECT * FROM t LIMIT $plimit+1

if ( $resnum > $plimit ) {

->nextpage ?page=2

}

un nākamais select - LIMIT $plimit*$page-1, $plimit+1

 

un tas pats atkārtojas. neredzu problēmas. ņem vērā, ka jāizvada ir $plimit ierakstu skaits nevis $plimit+1

kā jau teicu - ja nav svarīgi zināt ierakstu skaitu tad šitais variants ir ideāls, lai nebūtu gemaroja ar daudziem selectiem.

 

par sesijām - ņem vērā, ka jauni ieraksti varbūt parādās starplaikā... tā kā sesiju efektivitāte ir nu tāda... tāpat regulāri būs jātaisa selecti ar numrows apdeitiem

Link to comment
Share on other sites

Hemorojs ir sekojoš:

Ir modulis A un modulis B. Uz lapas liekam 20 ierakstus. Modulī A mēs atrodam 5. Modulī B ir, teiksim, 30 atbilastoši ieraksti. Ok, taisot selectu pirmajai lapai viss ir forši - dabonam ar LIMIT 0,$pagelimit+1 piecus ierakstus. Taisam selectu modulī B. Nu jau šitādu - LIMIT 0, $pagelimit-$res_founded+1. Un tālāk sākas hemorojs - taisot selectu priekš next page, man jāatcerās, kādā modulī man beidzās iepriekšējais selects, ar kādu ofsetu viņš beidzās... Ja ejam katru reizi cauri visam, skaitot ierakstus, tad, teiksim, modulī A pa to laiku ir parādījušies jauni ieraksti, tātad, priekš moduļa B būs k. kādi jauni ofseti, kuru rezultātā k. kādi ieraksti rādīsies vairākās lapās, vai taisni otrādi - vispār kaut kur pazudīs... To biš, kaut kādi viltīgi aprēķini ar šaubīgu rezultātu.

 

Par jauniem ierakstiem, kas parādās pa to laiku, kamēr staigā pa atrasto rezultātu lapām. Nu lai tak. Mēs jau rādam resultātu uz meklēšanas brīdi. Tev tak google ar neapdeito dinamiski ierakstu skaitu, pārejot uz nākamo rezultātu lapu ;)

 

P.S. bez tam, ir tak jauki, ja vari userim pateikt "Uz jūsu pieprasījumu atrasti x ieraksti" :)

Edited by john.brown
Link to comment
Share on other sites

Ir modulis A un modulis B. Uz lapas liekam 20 ierakstus. Modulī A mēs atrodam 5. Modulī B ir, teiksim, 30 atbilastoši ieraksti.

hm.. kaads tur gemorojs..?

var dariit sekojoshi...:

izveicam 3 dimensiju masiivu ar tabulas nosaukumu + ID ... pieseivojam sesijaa

un kaa no tabulas atlasam izveeleeto ierakstu

neaizmirsti ka masiivs var satureet n masiivus/objektus ;)

(daudzliimenju / dimensiju masiivi)

----

biskji veelaak uzrakstiishu arii kodu.... (apmeeram)

P.S. Kameer gaish jaiziet ar Gjimeni araa ;)

Link to comment
Share on other sites

Es saprotu, ka var uzrakstīt :) Tik man nez kāpēc liekas, ka dotajā gadījumā tas nav īsti lietderīgi. Ko mēs iegūstam? Sarežģītāku un mazāk saprotamu kodu, palielinātu noslodzi db, nespēju lietotājam pateikt, cik ierakstu atrasts... Ar plus zīmi nekas prātā nenāk...

Tomēr jau uzrakstīju ar rezultātu glabāšanu sessijā - strādā jauki.

Link to comment
Share on other sites

×
×
  • Create New...