john.brown Posted December 23, 2006 Report Share Posted December 23, 2006 (edited) 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 December 23, 2006 by john.brown Link to comment Share on other sites More sharing options...
bubu Posted December 24, 2006 Report Share Posted December 24, 2006 Kas vainas prastam selekteam ar limitu katru reizi? Link to comment Share on other sites More sharing options...
john.brown Posted December 24, 2006 Author Report Share Posted December 24, 2006 (edited) 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 December 24, 2006 by john.brown Link to comment Share on other sites More sharing options...
bubu Posted December 24, 2006 Report Share Posted December 24, 2006 Nu a nevar kautkā apvienot tos selektus? UNIONi/storētās procedūras? -- Nelieto Quick Edit, to laacz'is vēl labojot.. Link to comment Share on other sites More sharing options...
john.brown Posted December 24, 2006 Author Report Share Posted December 24, 2006 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 More sharing options...
hmnc Posted December 24, 2006 Report Share Posted December 24, 2006 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 More sharing options...
john.brown Posted December 25, 2006 Author Report Share Posted December 25, 2006 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 More sharing options...
hmnc Posted December 25, 2006 Report Share Posted December 25, 2006 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 More sharing options...
john.brown Posted December 25, 2006 Author Report Share Posted December 25, 2006 (edited) 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 December 25, 2006 by john.brown Link to comment Share on other sites More sharing options...
hmnc Posted December 25, 2006 Report Share Posted December 25, 2006 mde. nu tad tik atliek taisīt divus selectus pārbaudot cik ierakstu ir un izvadod rezultātus. un ta jau var sesijā iemest $totalrows katrai tabulai, bet nu ja bieži apdeitojas tabulas, tad tāpat būs diezgan bieži dubulti selecti. Link to comment Share on other sites More sharing options...
Grey_Wolf Posted December 25, 2006 Report Share Posted December 25, 2006 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 More sharing options...
john.brown Posted December 25, 2006 Author Report Share Posted December 25, 2006 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 More sharing options...
Recommended Posts