Mysql klase?

[codez]

Nezinu, kā tev, bet man DB::query() saglabā result objektu iekš DB objekta mainīga, jo biežāk tomēr pliku result man nav jāatgriež.

Pēc tam ērti darīties piemēram šādi

$clients = DB::query(..)->fetch_assoc();

 

Man šķiet, ka šijā gadījumā tev var sanākt kolīzijas, ja tev paralēli vajadzētu strādāt ar vairākiem result-iem.

Resulta objektu es neglabāju klasē, bet vienkārši atgriežu kā funkcijas return vērtību, tādā veidā:

 

DB::q()->fetch_assoc();

 

Bet vienu labu ideju tavi komentāri man pameta - ka es varu ekstendod mysqli_result as savu custom result klasi un izveidot aptuveni šādu funkcionalitāti:

DB::q() atgriež manu custom_result klasi, kurai ir šādas metodes:

 

DB::q(...)->one(); //atgriež pirmo kolonnu no pirmās rindas
DB::q(...)->one(5); // atgriež 5.-to  kolonnu no pirmās rindas
DB::q(...)->one(5,8); // atgriež masīvu ar vērtībām no 5.-8. kolonnai no pirmās rindas
DB::q(...)->row(); //atgriež da 1. rindu
DB::q(...)->row(4); //atgriež 4-to rindu
DB::q(...)->row(4,7);  // atgriež 2D masīvu 4.-7. rindai
DB::q(...)->all(); //atgriež 2D masīvu - visas rindas
DB::q(...)->cell(4,5); //atgriež 4. rindas, 5. kolonnu.

DB::q(...)->json(); //atgriež visu rezultātu json formā
DB::q(...)->xml(); //atgriež visu rezultātu xml formā

 

Bija jau nojausma, ka šij diskusijai jārada kāds pieņemams risinājums.

 

 

Ja PHP 5.2 strādātu maģiskā invoke metode, tad izmantojot to varētu klasi izmantot šādi

 

$user=DB('SELECT * FROM users')->all();

 

Kā funkciju to nevar taisīt, jo tad neizsauksies autoload-s.

Edited August 20, 2010 by codez

[Леший]

Resulta objektu es neglabāju klasē, bet vienkārši atgriežu kā funkcijas return vērtību, tādā veidā:

Bet, saglābājot klasē (precīzāk, objekta :P ), tev ir vairākās papildus ērtības gadījumos, kad tev ir jāizsauc papildus DB metodi, kurai arī ir jāstrādā ar to pašu rezultātu.

Piemērs:

Neseivojot rezultātu:

$result = DB::query(..);
$some_data = DB::some_method($result);
$some_other_data = DB::some_other_method($result);

Seivojot rezultātu:

$result = DB::query(..)->result();
$some_data = DB::some_method();
$some_other_data = DB::some_other_method();

 

EDIT: Vēl aizmirsu piebilst, ka ar dažiem query result vispār nav vajadzīgs, piemēram insert.

Edited August 20, 2010 by Леший

[codez]

Zināma loģika ir, bet vai tad labāk tās some_method()-es nelikt result objektā, ja viņas strādā ar resultu?

 

$result = DB::query(..);
$some_data = $result->some_method();
$some_other_data = $result->some_other_method();

[Kavacky]

Kavacky, diez vai tas daudz ko mainīs, jo tāda pieeja kur skaitlis norāda uz dimensiju noderēs tikai tad ja Tu paskatoties uz q() sapratīsi un zināsi ka tas pilnīgi noteikti ir query, nevis, piemēram quantity.

Nevajag arī būt āmuram, ka glEnable(GL_DEPTH_TEST) iztulko par to, ka šajā vietā zemūdenei jāčeko iegrimes dziļums. Konteksts.

 

 

Codez, šis iemesls nu vienkārši gāž mani gar zemi! :))

PHP tas točna nav aktuāli, problēmas rodas Java programmētājiem, kur bez vismaz 2 widescreen vienu rindiņu newrapotu neredzēt. :D

 

 

Bet, saglābājot klasē (precīzāk, objekta :P ), tev ir vairākās papildus ērtības gadījumos, kad tev ir jāizsauc papildus DB metodi, kurai arī ir jāstrādā ar to pašu rezultātu.

Ja pareizi sapratu, tad to problēmu risina tas, ka kverijam ir sava klase. Man katrs kverijs ir objekts, kurā tad var saukt dajebkādas metodes pēc vajadzības. Un kveriju izsaukt pie vajadzīgās DB ( kas atrodas citā objektā - DB klases instancē ).

 

Tik smalki par labu stilu nezinu, bet ja man nāktos suportēt projektu, kuru pirms tam sarakstīja ar šitādiem q1(), q2() utt, tad es labāk uzzinātu "meistara" adresi un atnāktu ciemos ar motorcirvi.

Nu, nu, ja tie nosaukumi būtu tik loģiski kā codez variantā, tad ar cirvi toč ciemos nav jāiet. Bet parasti jau tā nav, kāds radošā lidojuma ģēnijs ar katru no q1, q2, q3 ir domājis kaut ko pilnīgi citu. Kaut vai pēc kārtas numurējis metodes klasē, tas nekas, ka katra citam uzdevumam. :D

[Леший]

Zināma loģika ir, bet vai tad labāk tās some_method()-es nelikt result objektā, ja viņas strādā ar resultu?

 

$result = DB::query(..);
$some_data = $result->some_method();
$some_other_data = $result->some_other_method();

Tavs variants der, ja katrs kontroliera action darbojās ar 2-3 querijiem, bet, ja ir vairāki, tad performance ziņā šis variants nav optimāls. Pēc taviem postiem sapratu, ka esi AJAX-īgo aplikāciju cienītajs, un tieši AJAX-īgas aplikācijas reti darbojās ar vairākiem query. Pārsvarā, AJAX servera daļai vajag novalidēt lietotāju (1. querijs) un izdarīt pieprasīto action (2), kā arī saņemt datus (3).

[codez]

Tavs variants der, ja katrs kontroliera action darbojās ar 2-3 querijiem, bet, ja ir vairāki, tad performance ziņā šis variants nav optimāls.

Lai arī kādu abstrakcijas līmeni būvētu, db klasēm pati tā loģika no koda procesora noslodzes, ja vien nebūs kādas perversijas, aizņems mazāk par 1% no procesora noslodzes. Pārējais būs konekcija, TCP komunikācija, db servera darbs, datu pārsēšana, utt. Tāpēc šī vieta nebūs botleneck-s un tās performances optimizēšana nav aktuāla. Daudz, daudz svarīgāk ir rakstīt pareizus kverijus, salikt indeksus, utt.

Es savās aplikācijās esmu novērojis, ka 70-80% no visas kopējās procesora noslodzes patērē mysql serveris un komunikācija ar to.

 

Pēc taviem postiem sapratu, ka esi AJAX-īgo aplikāciju cienītajs, un tieši AJAX-īgas aplikācijas reti darbojās ar vairākiem query. Pārsvarā, AJAX servera daļai vajag novalidēt lietotāju (1. querijs) un izdarīt pieprasīto action (2), kā arī saņemt datus (3).

Es lietotāju varu novalidēt bez kverija,

action-a izsaukšasa tāpat ir bez kverija.

vienīgais - viens vai vairāki kveriji ir, lai iegūtu vajadzīgos datus.

 

Piemēram lietotājs atver atver apskatīties vēstules un viņam atverās logs, kurš izsauc ajax-īgu pieprasījumu nolasīt vēstules no inbox.

Action metode izskatīsies aptuveni šādi:

 

function getMessages(){
 if ($uid=MAuth::id()>0) {
   $offset=(int)$_POST['offset'];
   $count=LDb::q('SELECT count(*) FROM messages WHERE uidto=%s',$uid)->one();
   $msgs=LDb::q('SELECT m.*,u.un,u.img FROM messages m,users u WHERE m.uidfrom=u.id and m.uidto=%s ORDER BY m.sent DESC LIMIT %s,%s',$uid,$offset,MConst::$messages_per_page)->all();
   echo json_encode(array('c'=>$count,'msgs'=>$msgs));
 }  
}

Vienīgie kveriji šī ajax pieprasījuma izpildē būs kodā redzamie.

 

Pašlaik šajā piemēra nav realizēts, bet eksperimentālā stadijā man ir ajax kontrolieris, kurā ar vienu parametru jau norādītu, ka action-s var tikt izsaukts tikai ar ielogotu lietotāju un kontrolerim ir speciāls jsonresponse objekts. Tādā gadījumā šī pati funkcionalitāte ir pierakstāma ar 2. rindiņām, aptuveni šādi:

 

function getMessage_auth(){
 $this->response->json['c']=LDb::q('SELECT count(*) FROM messages WHERE uidto=%s',$this->request->uid)->one();
 $this->response->json['msgs']=LDb::q('SELECT m.*,u.un,u.img FROM messages m,users u WHERE m.uidfrom=u.id and m.uidto=%s ORDER BY m.sent DESC LIMIT %s,%s',$this->request->uid,(int)$_POST['offset'],MConst::$messages_per_page)->all();
}

[Леший]

Ar action es biju domājis jebkuru action, kas atšķirās no defaulta, kas parasti ir dati iegūšana.

Piemēram, lietotājs ir pievienojis ierakstu, nostrādāja action addRecord, un tad aiziet defaultais, kas ir datu iegūšana.

Un, par validāciju bez querija - nedomāju, ka tas ir good style, jo šitāda pieeja nekad nebūs secure.

[mefisto]

PDO FTW

+1