Jump to content
php.lv forumi

Daudz sql query VS daudz php loopi


mandarīnpīle
 Share

Recommended Posts

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?

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by mandarīnpīle
Link to comment
Share on other sites

  • 2 weeks later...

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...

Link to comment
Share on other sites

> 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.

Link to comment
Share on other sites

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ē.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...