count

[goma smile]

Vai nav tā, ka 6. rindiņā esošā pārbaude ir true arī tad, ja $_GET['a'] nav uzstādīts vai ir tukšs:

if(preg_match('/^[0-9]*$/i', $_GET['a']))

Kas notiek, ja nomaini uz:

if(preg_match('/^[0-9]+$/i', $_GET['a']))

?

Nemainas nekas vienalga pievienojiet komentāru atņemās no kopejā

 

Šis ir deomāts tas izvade ar echo .... ?

mysql_query(...);
pārveido par
mysql_query(...) or die(mysql_error());

arī neko nedo .... :D

[bubu]

Gan tas, gan arī šis:

echo $query_string;
mysql_query($query_string) or die(mysql_error());

[nemec]

Tomēr es izvēlos šo variantu.

 

Vai sekojot Alekseja tabulu nosaukumiem:

 

select r.id, count(k.id)
from jaunumi r
left join komentari k
 on (r.id = k.raksta_id)
group by r.id

Attiecīgi jāpapildina gan select saraksts, gan group by saraksts ar nepieciešamajām citām kolonām no jaunumiem.

Pievienojos tam, ka ļoti ticami, ka šādi selecti būs n reizes vairāk kā dažas komentāru dzēšanas un izdevīgāk ir lietot atvasinātu lauku.

 

Gints Plivna

http://datubazes.wordpress.com

 

Iemesli tam ir ļoti dažadi:

1) nav jāčakarējas ar pieskaitīšanu un atskaitīšanu, līdz kādas aktivitātes notiek komentrāru tabulā. Laiks un lieks darbs.

2) Ātrāk un īsāk. Nav lieka lauka. Nav lieka koda.

3) Nejūtu nekādu īpašu taupīšanu uz resursiem.

[Delfins]

Esi pārliecināts, ka ātrāk?

Esi redzējis, kas notiek ar lielāko daļu saitu, kad kāds sāk komentēt pie vairāku lasītāju skaita? Lapa vnk neiet, jo ir dead-lock. kamēr joino un taisa swap-u, kāds grib update uztaisīt un t.t.

Liekais kods? - pārs rindiņas?

 

"Nejūtu nekādu īpašu taupīšanu uz resursiem" - webā pats primārais = atsauces laiks (response time), ja lapa neiet vai bremzē, es vnk taisu ciet. Jebkurš lietotājs lamā jebkuru lapu, kas bremzē. Šeit jā'but vislielākajam respektam pret lietotāja laiku.

[Web Developer]

Ja jāizvēlas starp Delfina vai nemec viedokli, drīzāk piekrītu Delfinam.

Tieši tā - laiks ir būtisks. Cilvēki kļūst aizvien prasīgāki un izlutinātāki un sagaida, ka arī sarežģīts webs drīz jau būs tāpat kā desktop aplikācija - ātrs un funkcionāls. Tad kļūst būtiska arī programmēšanas kvalitāte, ne tikai tehnoloģija.

Paskatieties uz Drupal piemēram - funkcionalitāte plaša, iespējas samērā daudz (attiecīgā līmeņa webiem), bet bremzē kā elle - kam tas ir vajadzīgs? Tas ir viens no būtiskākajiem apstākļiem, kas nosaka pamatvērtējumu ļoti ātri!

[codez]

Labāk jaunumu tabulā glabāt komentāru skaitu, jo, ja piemēram satura lapā būs 30 raksti, kuriem gribēs iekaviņās norādīt komentāru skaitu, tad šādas lapas ģenerācijā mysqlam iekšēji nāksies izpildīt 30 count darbības, kas pie normāli aipildītas db un pat neliela lietotāju skaita var sākt radīt problēmas.

[goma smile]

Gan tas, gan arī šis:

echo $query_string;
mysql_query($query_string) or die(mysql_error());

 

Ar šo veicu pētijumus un noskaidroju :@.

 

tātad izmantoju echo protams tūr rāda pareizi, bet tabulā nepieskaita ....

Pieskaita

UPDATE jaunumi SET komentaaru_skaits=komentaaru_skaits + 1 WHERE id=3

 

Atņememšana

UPDATE jaunumi SET komentaaru_skaits=komentaaru_skaits - 1 WHERE id=3

 

 

Protams tad man ienāca ideja ka -1 + 1=0 tātad parvedojo

UPDATE jaunumi SET komentaaru_skaits=komentaaru_skaits + 2 WHERE id=3

 

 

 

Bet tad parādas brīnums ka tabulā pieskaita +2.

Edited February 24, 2009 by goma smile

[bubu]

Protams tad man ienāca ideja ka -1 + 1=0

Nesapratu - tu uzreiz pievieno un dzēs komentāru ārā?

[goma smile]

Ne es domāju ka kautkā iziet cauri atņemšanai .... un izdomāju ka nomainīt +1 uz +2 tad gan pieskaitās bet +2 :@

[Aleksejs]

Nevajag sarežģīt to, kas nav jāsarežģī!

Komentāra pievienošana un komentāra dzēšana pēc loģikas nedrīkst notikt vienlaicīgi - bet tieši tas Tev notiek.

Es vispār šīs lietas atdalītu dažādos failos/moduļos.

[nemec]

Esi pārliecināts, ka ātrāk?

Esi redzējis, kas notiek ar lielāko daļu saitu, kad kāds sāk komentēt pie vairāku lasītāju skaita? Lapa vnk neiet, jo ir dead-lock. kamēr joino un taisa swap-u, kāds grib update uztaisīt un t.t.

Liekais kods? - pārs rindiņas?

 

"Nejūtu nekādu īpašu taupīšanu uz resursiem" - webā pats primārais = atsauces laiks (response time), ja lapa neiet vai bremzē, es vnk taisu ciet. Jebkurš lietotājs lamā jebkuru lapu, kas bremzē. Šeit jā'but vislielākajam respektam pret lietotāja laiku.

explain man rāda, ka pieprasa tikai vienu lieku rindu.

Mani mērījumi php ar (1000 ziņām un 30000 komentāriem) arī nekādas būtiskas atšķirības nerāda. Iespējam nepareizi mēru.

Par laiku tev piekrītu, bet ir nopietnākas lietas kur taupīt.

Labot ir vieglāk vienā vietā, nevis vairākās - pie komentāru dzēšanas un pievienošanas.

Bet piekrītu jums, ka jūsu variants ātrāks (par cik, tas jau cits jautājums).

[goma smile]

Nevajag sarežģīt to, kas nav jāsarežģī!

Komentāra pievienošana un komentāra dzēšana pēc loģikas nedrīkst notikt vienlaicīgi - bet tieši tas Tev notiek.

Es vispār šīs lietas atdalītu dažādos failos/moduļos.

 

jā esu pārliecināts pa 99% ka tā arī ir ...

 

A varbūt var šajā gadijumā izlīdzēties ar kautko citu piemēram javascript....

[Aleksejs]

Nē!

 

Šajā gadījumā ir vienkārši jāsaved kārtībā tas, ko esi sataisījis un viss darbosies lieliski.

 

Nezinu, kā Tev viss tur izskatās, bet pieņemsim, ka šī lapa caur GET saņem komentāra ID: kid un raksta ID: rid (ja notiek dzēšana), vai arī caur GET raksta ID: rid un caur POST komentāra laukus: autors, komentars (ja notiek pievienošana).

 

Tad kods izskatās aptuveni šādi:

http://paste.php.lv/1ce4d0153530fec61c848a...355311?lang=php

[Grey_Wolf]

... arī nekādas būtiskas atšķirības nerāda. Iespējam nepareizi mēru.

Par laiku tev piekrītu, bet ir nopietnākas lietas kur taupīt.

Bet piekrītu jums, ka jūsu variants ātrāks (par cik, tas jau cits jautājums).

Visticamak ka meri pareizi :) , jo pie tik maza apjoma var Vispar neparadities atskjiriibas , tas atskjiriiba protams buus, bet tik nieciga ka var arii neizvadiities ( parak daudz ziimes aiz komata + OS iespejas meriit laiku ).

lapas ielades laiku var krietni vien paatrinat, neizmantojot Smagus Frimworkus, kas bremzee Krietni vien vairak nekaa DB lieka darbiiba, vel jo vairak ka taa tomer ir matimatiska operacija, kas pie musdienu Skaitljosanas atrumiem ir faktiski nebutiska.

Krietni vairak bremzees 1 lieka faila Incluuds nekaa shada nebutiska DB optimizacija .

Un ir labi zinams ka piemeram izmantojot JS freimworkus tiek ieladeeti Vairaki JS faili, kautgan dazreiz pietiktu ar nelielu pasa rakstiitu JS gabalu (1 -2 failu(iem) )

---

Vienmer jatceras ka faila atversana un iekljausana kodaa, buus Krietni lenaka nekaa 1 papildus darbiiba DB ...

taatad sakuma vajag padomat vai Izmantot gatavos freimworkus, vai tomer veidot savu kodu , pedejais kaa rada pieredz ir krietni atraks nekaa gatavie varinti

(kur katrai vissikakajai darbiibai ir savs fails ar atseviskju klasi, no kuras dazreiz izmanto tikai vienu funkciju )

---

Ginta blogaa , bija labs raksts par optimizaciju (piemers par brauksanu no Jurmala uz Riigu, nu luuk , juus paslaik Censaties Optimizeet pedejas 5 minuutes

celja, nevis Vietas kur laiks aiziet krietni vairaak.....

 

edit: un vel viens Ljoti butisks Pret skaitiisanu un rakstiisanu uzreiz -> Mysql 4.1.xx ir noverots gljuks ( pie itkaa elementaras darbiiabs x=x+1 ) ja lauks ir Unsignet tad var gadiities ka tiks parsniegts max pieljauta vertiiba un gala rezultataa iegusiet Pilnu Integer (tas ir maksimalo integer vertiibu ),

[ vienlaicigi padodot atnjemsanu un saskaitiisanu , tas ir 2 uzeri iedot 2 pretejas darbiibas ] , par so nerunatu, ja vien tepat foruma cilveki nebutu zelojusies ka bijusi sada problema, un pats arii nebutu saskaries ar sadu lietu-> gljuks izpauzaas ljoti, ljoti reti, bet tomer ir ..

Edited February 25, 2009 by Grey_Wolf

[Pentiums]

ja komentāru skaitu vajag izvadīt pie katra jaunuma/raksta tad es daru šādi:

SELECT raksti.*, COUNT(komentari.id) as kom_skaits FROM raksti LEFT JOIN komentari ON raksti.id=komentari.rid AND komentari.tips='raksts'
GROUP BY raksti.id
ORDER BY raksti.id DESC