Jump to content
php.lv forumi

Kā saskaitīt datus iekš datubāzes?


forSilence

Recommended Posts

Un man ir "kontroleri" kas strada ar tulkstošiem ierakstu.

 

Kotroleriem nevajadzētu vispār strādāt ar ierakstiem. To dara modeļi.

Bet nu ja gadījumā tev viena requesta laikā tiešām tiek strādāts ar tūkstošiem ierakstu, tad acīmredzami ir izvēlēta slikta aplikācijas arhitektūra.

 

 

Un, ko jūs te ņematies.

Ja vajag komentāru skaitu rakstam regulāri attēlot, tad ir pilnīgi skaidrs, ka attēlojumis būs 100-1000 uz vienu komnetāra ievadi, Tāpēc lai ko un kā optimizētu, daudz efektīvāk ir vienkārši glabāt rakstam komentāru skaitu un tad, kad pievieno/dzēš komentāru/s, atjaunot raksta statusu, kaut vai ar:

 

UPDATE articles SET comments=(SELECT COUNT(*) FROM comments WHERE aid=$aid) WHERE id=$aid;

 

Parasti raksta statusu pie komentēšanas tāpat ir jāatjauno, jo gribam ievietot laiku, kad pēdējo reizi raksts bijis aktīvs, lai rakstus kārtotu pēc aktivitātes. Utt.

Link to comment
Share on other sites

Tev tiešam ir kontrolieri, kas atlasa tukstošiem ierakstu no bāzes un apstrādā tos ar PHP?

Pagajuša darba vieta ta bija. Saita statistikas agrigešanai. Ta nebija apstradata kadu gadu un bija tabula 1 TB.

Bija protams probemas ar atmiņu, bet tiekam gala.

Es protams labak izmantotu kursuru Oracle procedura, bet tur bija bleņas ar tiesibam tapec izveidojam hacku.

Link to comment
Share on other sites

Kotroleriem nevajadzētu vispār strādāt ar ierakstiem. To dara modeļi.

Bet nu ja gadījumā tev viena requesta laikā tiešām tiek strādāts ar tūkstošiem ierakstu, tad acīmredzami ir izvēlēta slikta aplikācijas arhitektūra.

Vienkarši var but ta ka cilveks nestrada tikai ar web-saitiem.

Protams var pastrideties par terminoloģiju. Modele - ir pati datubaze un datubaze protams strada ar saviem ierakstiem.

Kontolers ir logika un ja man vajag to loģiku uz 1000 ierakstu, es ta ari darišu.

 

Un, ko jūs te ņematies.

Ja vajag komentāru skaitu rakstam regulāri attēlot, tad ir pilnīgi skaidrs, ka attēlojumis būs 100-1000 uz vienu komnetāra ievadi, Tāpēc lai ko un kā optimizētu, daudz efektīvāk ir vienkārši glabāt rakstam komentāru skaitu un tad, kad pievieno/dzēš komentāru/s, atjaunot raksta statusu, kaut vai ar:

 

UPDATE articles SET comments=(SELECT COUNT(*) FROM comments WHERE aid=$aid) WHERE id=$aid;

 

Parasti raksta statusu pie komentēšanas tāpat ir jāatjauno, jo gribam ievietot laiku, kad pēdējo reizi raksts bijis aktīvs, lai rakstus kārtotu pēc aktivitātes. Utt.

Šis proces saucas par denormaliciju. Un tiek izmantots ja vajcajums nepeitiekami atri strada.

To vajadzetu darit datubazē ar TRIGGER palidzibu. Lai istenotu DRY principu.

Bet domat par efektivitati veitas kur tas nav vajadzigs - nav vajadzigs. Jo augstak minets vaicajus stradas ar apmirinošu laiku.

Link to comment
Share on other sites

Vienkarši var but ta ka cilveks nestrada tikai ar web-saitiem.

Protams var pastrideties par terminoloģiju. Modele - ir pati datubaze un datubaze protams strada ar saviem ierakstiem.

Kontolers ir logika un ja man vajag to loģiku uz 1000 ierakstu, es ta ari darišu.

Model-is nav tikai pati datubāze, bet arī visa biznesa loģika, kas apstrādā datubāzē esošos datus.

Savukārt kontroleris ir loģika, kas apstrādā request-u, izvēlas, kuru modeļus izmantot un to datus nodod view-am izvades ģenerēšanai.

 

To vajadzetu darit datubazē ar TRIGGER palidzibu. Lai istenotu DRY principu.

Elementārā gadījumā to varētu darīt ar pašas db trigger-a palīdzību, bet, izmantojot labu php modeļu klasi, šādus trigerus pavisam ērti ir rakstīt PHP pusē un vienozīmīgi tie ir jāraksta PHP pusē, ja vēlamies izmantot kaut kāda veida kešošanu (piem., memcached). Piemērs, ierakstām jaunu kometāru, bet dati par rakstu glabājās kešā, šijā gadījumā db trigeris izdarīs lieku darbību, jo tik un tā nāksies izmainīt datus par rakstu kešā, kuri vēlāk tiks pārrakstīti pa virsu trigera veiktajai darbībai.

Link to comment
Share on other sites

Modeļi tikai atlasa/ieraksta ierakstus, tāpēc tie arī ir modeļi. Kontrolieri apstrādā datus.

 

Teiksim aplikācija izmanto virtuālo naudu un ir funkcionalitāte, kurā nauda tiek nosūtīt, tai tie atrēķinātas komisijas, pievienota saņēmējam, atņemta sūtītājam, respektīvi darbības ir krietni vairāk kā datu atlasīšana un ierakstīšana.

 

Tagad tev šo darbību vajag, lai viņa strādātu gan WEB-iskajā lapas versijā, gan API.

Ir pilnīgi skaidrs, ka vebiskajai versijai un API būs dažādi kontroleri. Ja tu šo funkcionalitāti liksi kontroleros, tad tev nāksies tu dublēt, kamēr liekot modelī, tu vari no katra kontrolera izmantot attiecīgo modeli un nekāda funkcionalitāte nedublēsies.

Link to comment
Share on other sites

Par to jau es runāju, tu saki, ka kontroleri apstrādā datus, bet es saku, ka modeļi apstrādā datus, bet kontroleri šos datus tikai padod modelim (izsauc metodi), tos neapstrādājot. Jo, ja kontroleri apstrādās datus, tad manā dotajā piemērā būs divas reizes jāraksta datu apstrāde WEB un API kontroleros, bet, ja to dara modeļi, tad vienu reizi, tikai modelī.

Link to comment
Share on other sites

Visu topiku neizlasīju, bet sākumu gan, un piekrītu codez variantam, ka jāliek kolona 'komentaru_skaits' `news` tabulā, jo:

1) ja izmanto myisam kā tabulas dzinēju, tad count(*) tiek paņemts no metadatiem. (myisam pie katra insert/delete pieglabā cik ir ierakstu tabuā [skaitu])

2) ja būs 'select count(*) from tabula where x=y', tad netiks izmantots myisam saglabātā vērtība, bet gan skaitīti rezultāti (kas pie daudz ierakstiem būs lēns process)

3) ja tabulai būs dzinējs innodb, tad count skaitīs visus ierakstus tabulā (jo innodb ir row locking nevis table locking)

 

un atspoguļojot jaunumus , nebūs jātais selekti uz citām tabulām (ātrāk notiks ielāde)

 

var arī komentu tabulai pielikt 2 trigerus, viens dzēšanai, otrs pievienošani (kas izmainīs komentaru_skaits vērtību news tabulā)

Link to comment
Share on other sites

Teiksim aplikācija izmanto virtuālo naudu un ir funkcionalitāte, kurā nauda tiek nosūtīt, tai tie atrēķinātas komisijas, pievienota saņēmējam, atņemta sūtītājam, respektīvi darbības ir krietni vairāk kā datu atlasīšana un ierakstīšana.

 

Tagad tev šo darbību vajag, lai viņa strādātu gan WEB-iskajā lapas versijā, gan API.

Ir pilnīgi skaidrs, ka vebiskajai versijai un API būs dažādi kontroleri. Ja tu šo funkcionalitāti liksi kontroleros, tad tev nāksies tu dublēt, kamēr liekot modelī, tu vari no katra kontrolera izmantot attiecīgo modeli un nekāda funkcionalitāte nedublēsies.

 

šajā gadījumā es liktu funkcionalitāti klasē un izsauktu kotrolleros, bet nu nejau modelī. Modelī ir visādi fetchi un varbūt kaut kāda triger funkcionalitāte

Link to comment
Share on other sites

Par to jau es runāju, tu saki, ka kontroleri apstrādā datus, bet es saku, ka modeļi apstrādā datus, bet kontroleri šos datus tikai padod modelim (izsauc metodi), tos neapstrādājot. Jo, ja kontroleri apstrādās datus, tad manā dotajā piemērā būs divas reizes jāraksta datu apstrāde WEB un API kontroleros, bet, ja to dara modeļi, tad vienu reizi, tikai modelī.

Ja, tev ir taisniba. Es velreiz izlasiju par to paterni. Vienkarši taja aplikaciju veida ar kuriem es tagad grasos stradaju ir loti maza starpiba starp controller un view.

Jo tie paši metodi kuri atbild par datiem ari izsaucas no konkretas view. Sanak kad maiņa sparp model vai controller notiek tikai no konteksta izmaiņas. Kas ir automatiska.

Link to comment
Share on other sites

šajā gadījumā es liktu funkcionalitāti klasē un izsauktu kotrolleros, bet nu nejau modelī. Modelī ir visādi fetchi un varbūt kaut kāda triger funkcionalitāte

Protams, ka liktu klasē, ja izmanto OOP, jo jebkurš kontroleris būs klase un jebkurš modelis būs klase un vispār programmējot OOP viss būs klases.

Tavs teikums ir nedaudz neloģisks, jo tu salīdzini lietas no dažādiem abstrakcijas slāņiem.

 

Bet, ja tu domāji, ka tu vienkārši šos aprēķinus liktu kaut kādā bilbiotēkā, tad tas ir absurds no MVC paterna viedokļa likt aplikācijas specifisku biznesa loģiku bilbiotēkās. Biznesa loģiku liek modelī.

 

Modelis tāpēc ir arī paredzēt, lai nodrošinātu abstrakcijas slāni attiecībā pret datiem.

 

Ja man ir modelī funkcija

 

$user->sendMoneyToUser($uidto);

 

tad šī funkcionalitāte man ir modelī un, ja es pēkšņi mainu db struktūru un man savādāk ir jāglabā un jāapstrādā dati, tad es mainu tikai un vienīgi modeli, kurš nodrošina šīs metodes sendMoneyToUser() viennozīmīgu darbību. Ja man vajag pievienot, lai katrs naudas pārsūtījums logotos, es to daru modelī.

Link to comment
Share on other sites

Kaut kādas vienkāršas lietas(atlasīt kādu ierakstu, aprēķināt kaut ko) var likt modelī. Vai nu kaut kādas darbības pie insert, update, delete. Bet kaut ko smagāku... nu nezinu. Piemēram var saņemt naudu no klienta vai vendora. Darbības stipri lidzīgas tātad jāveido abstrakto klasi un tad extendot to. Tad sanāk abstraktais modelis, kurš pie tam izsauc daudzu citu modeļu funkcijas, kuras arī var būt hierarhiskas. Nu tad kur ir tas "abstrakcijas slānis attiecībā pret datiem".

Link to comment
Share on other sites

Ja dati datu apstrāde vienā modelī ir atkarīga no cita modeļa datiem, tad viņi ir atkarība un tur nekāda aplikācijas struktūra to nemainīs. Taču hireahāla atkarība neizslēdz datu modeļa abstrakcijas iespējamību. Tāpat modelim no kura būs atkarīgs modelis būs kaut kāda metode, bet šī metode būs viennozīmīga un nodrošinās modeļa, no kura ir atkarīgs otrs, abstraktuma slāni.

 

Piemēram,

$user->senMoneyToUser()

 

var sevīs izsaukt

 

$transaction->addMoneyTransaction($uid1,$uid2,$data);

 

Bet abi modeļiem ir abstrakcijas slāņi, jo mēs varam kā glabāt naudas transakcijas mysql, tā vienkārši logot failos. Par to mums atbildēs transakcijas modelis, tālāk sniedzot mums savas metodes (abstrakcijas slaņi).

Jā, user modelis būs atkarīgs no transakcijas modeļa, bet tie nodrošinās katrs savu abstrakcijas slāni.

Ja aplikācijai specifisko datu apstrādi (biznesa loģiku, angliski - domain logic) ievietos bibliotēkās, tik un tā pastāvēs hirearhāla atkarība, bet biznesa loģika tiks izmētāta pa vietām, kur tai nav jāatrodas. Tāda jau ir MVC paterna būtība - organizēt aplikācijas struktūru viegli uztveramā veidā.

Edited by codez
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...
×
×
  • Create New...