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

[Леший]

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

[codez]

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.

[Vhubuo]

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.

[Vhubuo]

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.

[Леший]

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

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

[codez]

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.

[codez]

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.

[Леший]

codez, kas aizliedz dažādos kontrolieros izmantot vienu modeli? Un kas aizliedz no kontroliera izsaukt modeļa metodi?

[codez]

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

[Klez]

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ā)

[php newbie]

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

[Vhubuo]

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.

[codez]

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

[php newbie]

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

[codez]

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 September 16, 2010 by codez