mandarīnpīle Posted January 11, 2014 Report Share Posted January 11, 2014 Lapā ir vairākas tabula ar kopumā ~600 šūnām. Katrā šūnā ir dinamiski dati, kas ievākti no datubāzes. Query struktūra visur ir vienāda, bet parametri atšķirīgi (piem 1. šūnā where `something`=1 bet 2. šūnā where `something`=2) Kā būtu labāk? 1. Ģenerējot html katrā šūnā palaist query ar īpašajiem parametriem. => 600 query kopā. 2. Sākumā ievākt visus datus no DB. Ģenerējot html, katrā šūnā palaist php loopu, kas iet cauri sākumā ievāktajiem datiem un salīdzina vai tie atbilst parametriem. => 1 query kopā, 600 php loopi kopā. No koda lasāmības 1. variants ir daudz glītāks. Bet ko tas dara ar ātrumu? Quote Link to comment Share on other sites More sharing options...
daGrevis Posted January 11, 2014 Report Share Posted January 11, 2014 Vari parādīt piemēru no datubāzes struktūras? Kam tur būtu jāglabājas un kā tu to glabā? Quote Link to comment Share on other sites More sharing options...
Blitz Posted January 11, 2014 Report Share Posted January 11, 2014 atkarīgs no datu daudzuma ko tam php būs "jālūpo". Quote Link to comment Share on other sites More sharing options...
briedis Posted January 11, 2014 Report Share Posted January 11, 2014 Nafig jālaiž 600 lūpā? var tak atlasīt pa čupai (SELECT data WHERE id IN (čupa ar ID))\ Ja tur nav kaut kādas perversijas, tad šo varētu atrisināt 2 kvērijos. Karoč, vajag zināt, kas tev tur par struktūru, citādi neko precīzi nevar ieteikt. Quote Link to comment Share on other sites More sharing options...
mandarīnpīle Posted January 11, 2014 Author Report Share Posted January 11, 2014 (edited) Tajā tabulā ir lekciju saraksts kādai skolai. Mainīgie query ir šūnās, kas piedāvā brīvstundās ievadīt kādu lekciju. Piedāvāt drīkst tikai tādas lekcijas: pieejamas konkrētajam kursam Pasniedzējs dotajā dienā un stundā nepasniedz citu lekciju Datubāzē ir tabulas: TeachingRelation, ar laukiem id, grade_id, teacher_id subject_id. Tā norāda kurš pasniedzējs kurai klasei māca kuru priekšmetu. Lesson, ar laukiem id, teaching_relation_id, day_id, plkst_id, cabinet_id. Norāda kurā dienā, kurā kabinetā plkst cikos notiek TeachingRelation definētais mācību process. Jeb relācijas: TeachingRelation has many lessons. Lesson belongs to TeachingRelation. kabinets, diena, plkst belongs_to Lesson. priekšmets, skolotājs belongs_to TeachingRelation. Datu daudzums: 300 TeachingRelations 600 Lessons Gala rezultātā jātiek pie datiem no tabulas TeachingRelation. Katrā šūnā pieejami 3 izejas mainīgie - kurss, diena, pulksteņa laiks. Kas, virzoties uz priekšu sarakstā, mainās. Līdz ar to mainās arī query. Mans šā brīža risinājums, kas notiek katrā šūnā: Blacklisto TeachingRelations, kuras nav pieejamas. Query ir kaut kas uz šo pusi: select teaching_relation.* from teaching_relation left join lesson on teaching_relation.id = lesson.teaching_relation_id where teaching_relation.grade_id = x where lesson.day_id = x where lesson.plkst_id = x Izvada visas TeachingRelations, kas nav blacklistotas. (Pie esošās struktūras uzreiz tikt pie whitelista liekas, ka nevar.) Edited January 11, 2014 by mandarīnpīle Quote Link to comment Share on other sites More sharing options...
Grey_Wolf Posted January 20, 2014 Report Share Posted January 20, 2014 Manuprāt jātaisa 600 query, nevis 1 liels query un tad jāčakarējas php pusē. Tu tikai pārrakstītu visu jau esošo sql loģiku php valodā. Ja visi foreign_keyi datubāzē ir indexēti, tad 600 mazi DB accessi varētu būt tik pat ātri kā viens liels access un 600 php loopi. Turklāt lieki nesarežģīsi kodu. Nepareizs piegājiens pašā saknē, jo viss lielākā bremze parasti , ir datu padošana no SQL uz PHP .. saucamais 'pudeles kakls' vienkāršs aprēķins - ja pieslēgšanās + datu nosūtīšna aizņems 0,1 sek tad 0,1X600 var sanākt 6 sekundes Pat liels qverījs kas izpildīsies 3 sekundes SQL pusē , nostrādās 2 reizes ātrāk .. to vienmēr der atcerēties .. Protams ja tas ir kāds stundu atlases algoritms, tad ātrdarbība var vispār nespēlēt nekādu komu - teiksim vienlaicīgi pieslēdzas Max 10 cilvēki - tad labāk, ir izveidot stabīli strādājošu, kaut lēnāku, skriptu .. un uz ātrumu neiespringt... Quote Link to comment Share on other sites More sharing options...
daGrevis Posted January 20, 2014 Report Share Posted January 20, 2014 > saucamais 'pudeles kakls' Īstenībā par bottleneck sauc lietu, kas attiecīgajā aplikācijā aizņem procentuāli lielu izpildes laiku, tā, ka salabojot to, aplikācija būs N reizes ņiprāka un par citām lietām, kas arī *nedaudz* bremzē, pat var neuztraukties. Ļoti bieži tā ir datubāze, tas gan. Quote Link to comment Share on other sites More sharing options...
mandarīnpīle Posted January 20, 2014 Author Report Share Posted January 20, 2014 vienkāršs aprēķins - ja pieslēgšanās + datu nosūtīšna aizņems 0,1 sek tad 0,1X600 var sanākt 6 sekundes Pat liels qverījs kas izpildīsies 3 sekundes SQL pusē , nostrādās 2 reizes ātrāk .. to vienmēr der atcerēties .. Protams ja tas ir kāds stundu atlases algoritms, tad ātrdarbība var vispār nespēlēt nekādu komu - teiksim vienlaicīgi pieslēdzas Max 10 cilvēki - tad labāk, ir izveidot stabīli strādājošu, kaut lēnāku, skriptu .. un uz ātrumu neiespringt... Sākotnējais risinājums (neapdomīgi lietojot ORM) ar veselu kvēriju kaudzi izpildījās 1.5 sekundēs. Visus datus ielasot vienā kvērijā un tad loopojot php pusē visa padarīšana ielādējās 0.1 sekundē. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.