[sidrs]

Tad sanak tas kods šāds?
Parbaudiju ,itka šancē

$result = mysql_query("SELECT id FROM users where atlase='1'");
    	 while($row = mysql_fetch_assoc($result)){
	 $user=$row['id'];
        
         $rand1=rand(1,100);
         $rand2=rand(1,100);
         $rand3=rand(1,100);
         $rand4=rand(1,100);
         $rand5=rand(1,100);
         $rand6=rand(1,100);
         
         mysql_query("UPDATE users SET aile=$rand1 WHERE id='$user'");
         mysql_query("UPDATE users SET aile=$rand2 WHERE id='$user'");
         mysql_query("UPDATE users SET aile=$rand3 WHERE id='$user'");
         mysql_query("UPDATE users SET aile=$rand4 WHERE id='$user'");
         mysql_query("UPDATE users SET aile=$rand5 WHERE id='$user'");
         mysql_query("UPDATE users SET aile=$rand6 WHERE id='$user'");
}

un ja ir tikai 3 useri tad 3 rindiņas aiziet tipa pa tukšo?

[waplet]

kvēriju arī tikai vienreiz.

[sidrs]

Nu tad man beigu kods sanāk šāds :)

	 $result = mysql_query("SELECT id FROM users where atlase='1'");
	 while($row = mysql_fetch_assoc($result)){
	 $user=$row['id'];

	 
     mysql_query("UPDATE users SET aile='".rand(1,100)."' WHERE id='$user'");

    }

senkjū :)

[waplet]

Your welcome.

[2easy]

taču tas nenovērš atkārtošanās iespējamību :P
sanāk, ka tas ko mēs ar Gintu Plivnu rakstījām, ir kaķim zem astes...

izskatās, ka te programmēšanas vietā notiek kkāda koda uzminēšanas spēle! :D:D:D

[Gints Plivna]

Yeahh, nevienam ar varu mutē neko neieliesi, kā zināms šodien ir uzskatu brīvība un katrs dara kā viņš māk. No vienas puses, ja tā padomā, ja cilvēkam strādā un ir OK, tad ko vairāk vajag? No otras puses, protams, ja ar tādu pieeju darbosies mūžīgi, tad "kaut kā" arī strādās vienmēr...

Šai ziņā gribu pareklamēt savu raksteli Paradigmas maiņa – SQL ātrdarbības atslēga. Šai konkrētā gadījumā gan galīgi nav vērts iecentrēties uz kaut kādu ātrdarbību, kas acīmredzot ir gana nesvarīga, bet drīzāk mēģināt pielietot principu un paskatīties kaut ko jaunu, skaistāku un elegantāku tā vietā, lai visu kā parasti darbinātu ierakstu pa ierakstam.

Un pat ja nesanāk šajā reizē, tad tomēr par to atcerēties nākošreiz vai aiznākošreiz...

Gints Plivna
http://datubazes.wordpress.com

[2easy]

ātrumā pārgāju pāri par tām kopām. hmm nju iekš insert es šad tad mēdzu rakstīt uzreiz vairākas rindas VALUES (...), (...), (...) lai nebūtu jāveic vairāki inserti. taču kā ir ar update. vienā update kverijā taču nevaru norādīt šim id=1 uzsetot vards=aaa, tam id=234 uzsetot vards=bbb. tāpat jau tā kopu darbība tehniski reducējas uz atsevišķu rindu darbībām. vienīgi kkādas nelielas optimizācijas var nākt klāt

[sidrs]

Galvenais uzdevums man bija lai ieliek dažādus skaitļus useriem,jo vislaik man likās visiem vienāds.
Bet apsolos brivākā brīdi pamēģināt uzveidot lai randoms neatkartotos :)

un neko nemēģinu uzminēt, bet kauko censties iemācīties :)

[Gints Plivna]

2easy, on 2010.03.07 21:34, said:

taču kā ir ar update. vienā update kverijā taču nevaru norādīt šim id=1 uzsetot vards=aaa, tam id=234 uzsetot vards=bbb. tāpat jau tā kopu darbība tehniski reducējas uz atsevišķu rindu darbībām. vienīgi kkādas nelielas optimizācijas var nākt klāt

Nu tātad, protams, nevajag krist galējībās un pārvērst to par obligātu un nepārkāpjamu likumu, bet es Tev varu pastāstīt analoģiju. Ja Tev no veikala vajag 100 pakas pienu, tad taču Tu neskriesi uz veikalu 100 reizes un neņemsi katru reizi pa vienai pakai. Tu vai nu nesīsi vismaz pa 10-20 (cik nu spēks kaulos), vai arī paņemsi mašīnu un aizbrauksi pakaļ un atvedīsi visu vienā rāvienā. Tur nez kāpēc cilvēki saprot kā tas jādara. Taču diemžēl ar datubāzēm kaut kā parasti nē :(

Tātad tagad par tehniskākām lietām. Ja nepieciešams veikt izmaiņas kaut kā pilnīgi nesaistīti bez jebkāda saprātīga algoritma, tad, protams, ka katru ierakstu visdrīzāk nāksies koriģēt atsevišķi. Taču šeit runa ir par tiem gadījumiem, kad nākas apstrādāt daudz ierakstus un to apstrāde notiek kaut kā saprātīgi, pēc noteikta algoritma, piemēram, atskaites vai kaut kāda datu kopēšana, vai lūk cilvēkam vajag uzstādīt gadījumskaitli...

Par šo izteikumu - kopu darbība tehniski reducējas uz atsevišķu rindu darbībām.

Protams, ka tehniski galu galā DBVS kaut kādā vietā (vai itin bieži vairākās vietās - domā par indeksiem) failā iebaksta to izrēķināto vērtību. Taču pirms iebakstīt to vērtību norisinās ilgs un grūts process, lai līdz iebakstīšanai nonāktu. Es varu šeit īsumā uzskaitīt pamatlietas kā tas notiek Oraclē, bet 1kārt tās noteikti nav visas lietas, 2kārt citās DBVS būs diezgan līdzīgi.
Tātad programmēšanas valoda dod SQL teikumu izpildei:
- pings pa tīklu uz DBVS
- DBVS ierauga SQL teikumu un sāk tā apstrādi
-- validācija, ka tas ir korekts SQL teikums (sintakse)
-- tiesību pārbaude uz iesaistītajiem objektiem
-- SQL teikuma izpildes plāna meklēšana kešā
-- ja kešā neko neatrada, tad jāģenerē jauns SQL teikuma izpildes plāns, kas nozīmē statistiku apskati objektiem, iespējamo pieejas operāciju ģenerēšanu, iespējamo savienojumu (join) kombināciju pārbaudi etc etc
- SQL teikuma izpildi, ja tas bija updeits:
-- jāatrod ieraksts ko jāmaina. Ja tas, piemēram, ir viena ieraksta updeits pēc id, tad tas nozīmē, ka jāskanē cauri viss PK indeksa koks no augšas un jāatrod lapa kurā ir norāde uz tabulas ieraksta bloku
-- tabulas blokam jāizveido jauna kopija, jo veco kāds vēl varētu gribēt lasīt (atceramies, par to ka citi redz tikai commitotus datus)
-- jāieraksta izmaiņas tabulas datu blokā
-- jāieraksta izmaiņas indeksa datu blokā, ja tādas nepieciešamas
- pings atpakaļ uz izsaucošo programmu

Tātad, ja mums SQL teikums ir 1, ko mēs ietaupam:
- pingus pa tīklu (vai kaut vai tas ir uz 1 dzelža, jebkurā gadījumā kaut kāda mētāšanās pa kaut kādu sazināšanās vidi notiek) vienādi otrādi (aizņem relatīvi ļoti daudz laika)
- SQL teikuma sintakses validācijas, tiesību validācijas un kā minimums meklēšanu kešā (atkarībā no keša lieluma var nebūt patīkama operācija, pie tam jāatceras, ka kamēr apstaigā atmiņas objektus un it sevišķi tos maina - tā ir viena lietotāja ekskluzīva operācija, visi citi gaida, ja citu ir daudz, tad gaida ilgi)
- tā vietā lai n reizes skanētu indeksu atkal sākot no augšas, var gadīties, ka var izmantot efektīvākus pieejas ceļus
- ja datu bloks jau bija atrasts un izrādījās, ka nākošais labojamais ieraksts ir turpat, vai ir jau labots šai piegājienā, tad nav tas jāmeklē no jauna/vai vismaz nav jāveido tam nākošā kopija.

100 punkti, ka tā ir tikai daļa no darāmā un ka esmu kaut ko aizmirsis relatīvi svarīgu. OK MySQLā kaut kas no tā izpaliek (piemēram, datu blokus iespējams nekopē), bet Ja ir vēlme paskatīties, kā notiek viena SQL teikuma apstrāde, tad palaid MySQL profaileri un paskaties, kas par darbībām notiek viena nožēlojama SQL teikuma izpildē.

Un kā jau teicu - nav jēgas saspringt par sīkumiem, 3 lietotāju sistēmai ar 100 ierakstiem un 100 pieprasījumiem dienā, var rakstīt kā grib, vienalga visdrīzāk viss lidos. Tikai šai lietai ir potenciāli vismaz 2 draudi:
- 3 lietotāju sistēma ar 100 ierakstiem dažkārt mēdz izaugt par 3K lietotāju sistēmu ar 100M ierakstiem
- ja programmētājs citu pieeju nav zinājis, tad viņš arī pat zinot, ka sistēmā būs 3K lietotāji un 100M ieraksti, nemācēs uzrakstīt neko labāku.

Fuuuuu nu gan sacerējumu uzrakstīju :)

Gints Plivna
http://datubazes.wordpress.com

[2easy]

nuu tiešām tādu palagu piesmērēji :P

[2easy]

izlasīju! :))
nju jā, uz menedžmentu jau, protams, kkas ietaupās, ja darbību tiešām izdodas iecīnīt vienā kverijā ;)

anyway, imho, optimizēt vajag tad, kad to patiešām vajag. un ja datu/apmeklējumu apjoms arī uzaug ļoti liels, tad var izrādīties, ka ar softa optimizēšanu var nepietikt. var gadīties, ka vajag vairākus serverus pat pie visnooptimizētākā asemblera koda. tā ka ar pāragru optimizēšanu tiešām var droši nepārcensties :D

Quote

The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!): Don't do it yet.

- Michael A. Jackson

[Gints Plivna]

Viena lieta ir optimizēt. Otra lieta ir apriori nerakstīt sūdīgi, piedodiet par izteicienu.
Šī man ir tāda visai tuva un mīļa tēma, jo es savā apmaksātajā darbā vidēji reizi pāris nedēļās veltu zināmu laiku šādiem uzdevumiem. Itin bieži izrādās, ka nevis pasākums nebija optimāls, bet bija vienkārši sūdīgs.
Reizēm gribas paņemt cirvi un gāzt vainīgajam pa galvu, bet tad reizēm mēdz izrādīties, ka viņš jau ir atlaists ;) Iespējams, ka, ja nebūtu tik tizli rakstījis, nebūtu atlaists. Otra iespēja, protams, ir, ka tagadējie kolēģi noveļ vainu uz aizgājušo :D

[2easy]

Gints Plivna, on 2010.03.08 00:45, said:

Otra iespēja, protams, ir, ka tagadējie kolēģi noveļ vainu uz aizgājušo :D

kriminālajā pasaulē ir tas pats. ja aizturētie bandas locekļi visu vainu noveļ uz kādu vienu personu, tad ir skaidrs ka tā persona ir vai nu drošībā vai arī zem zemes... :D:D:D