jurchiks

Optimizācijām ar nelasāmu kodu nav nekāda sakara, nelasāms kods mēdz būt gan ar, gan bez optimizācijām. Pēc manas pieredzes tieši bez optimizācijām parasti ir nelasāmāks.

You're welcome :) P.S. tiem, kam baigās pretenzijas pret optimizēšanu - debagojot kodu un to optimizējot, var ļoti daudz ko iemācīties, un tas, ko iemācies, ātri vien pārvēršas pieradumā, turpinot programmēt, tu tās optimizācijas iekorporē kodā pat nedomājot. Vienīgais veids, kā tas var būt slikti, ir ja ar optimizēšanu nodarbojas non-stop. Mūsdienās vispār programmētāju, kuri raksta drausmīgi neoptimizētu kodu (kamēr strādā, tikmēr pofig, ja nolūzīs, tad kaut ko uzhakos), ir savairojies daudz par daudz; nezinu, kā jums, bet man tas derdzās.

Kas jums ir pret prepared statements? Tas, ka tiem ir ierobežots pielietojums, nenozīmē, ka tos vispār nav vērts izmantot!

Atstāj sākotnējo variantu, tas izskatās visnormālāk. Vienīgi $("#xxx") saglabā mainīgajā.

Tāpēc, ka ir tā vērts.

Ieinstalē xdebug + Chrome plaginu xdebug helper: https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc Nokonfigurē xdebug, ieslēdz profiling. Mans xdebug configs (iet php.ini apakšā): [XDebug] zend_extension = "C:/php/php_xdebug-2.2.2-5.5-vc11.dll" xdebug.default_enable = 1 xdebug.remote_enable = 1 ;xdebug.auto_trace = 1 ; makes apache restart with every request... ;xdebug.scream = 1 ; disables @ error suppression in PHP scripts ;xdebug.remote_log = "C:\Apache24\logs\xdebug.log" xdebug.show_mem_delta = 1 xdebug.collect_vars = 1 xdebug.collect_return = 1 xdebug.collect_assignments = 1 xdebug.show_local_vars = 1 xdebug.collect_params = 1 ; may consume a lot of memory ; xdebug.show_exception_trace = 1 ; shows exception trace (even if exception is caught) xdebug.profiler_enable_trigger = 1 ; allows triggering profiler from browser xdebug.profiler_output_dir = "C:\Apache24\logs\profiler" xdebug.profiler_output_name = cachegrind.out.%H_%R.profile xdebug.trace_enable_trigger = 1 ; allows triggering tracer from browser xdebug.trace_output_dir = "C:\Apache24\logs\tracer" xdebug.trace_output_name = cachegrind.out.%H_%R.trace Atver pieprasījuma lapu Chrome, xdebug helperī uzstādi profiling un veic pieprasījumu.Pēc tam ar WinCacheGrind (alternatīvu tūļu nosaukumi ir atrodami xdebug helper aprakstā) atver profiling logu un skaties, kas prasa visvairāk laika, ko var optimizēt, utt.

Jā, ir tiem prepared statementiem ierobežojumi, bet tas vienalga ir labāk, nekā visos kverijos hardkodēt vērtības, tādiem kverijiem gandrīz nekad nav iespējams izmantot query cache, jo vērtības visu laiku mainās. Ja ir pieejama iespēja datubāzei pašai optimizēt kverijus, tad kāpēc gan to neizmantot? Pat ja tikai 25% kveriju izmantos kešu, tas vienalga ir daudz labāk nekā 0%. Ja tu taisi kaut kādu kredītu sistēmu, tad varbūt ir vērts pārbaudīt visu un visur, bet, kā manā piemērā redzams, ir labāki risinājumi nekā katrā otrajā līnijā pārbaudīt iespējamās kļūdas, kuras 99.999% gadījumu nenotiks.

@Kavacky - lies, all lies!

@Wuu - tavā kverijā nav neviena parametra, tur prepared statement gan nav jēgas izmantot. Un vispār, tu tur ieslīgsti paranojā ar tām pārbaudēm. Šim kodam vajadzētu mest exceptions pie jebkādām problēmām: mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); // kaut kur pie savienojuma izveidošanas try { $pstmt = mysqli_prepare($link, 'SELECT col1, col2 FROM excel_online'); // $error = mysqli_stmt_bind_param($pstmt, 's', $item['item_name']); mysqli_stmt_execute($pstmt); mysqli_stmt_bind_result($pstmt, $col1, $col2); while (mysqli_stmt_fetch($pstmt)) { echo "{$col1}, {$col2}\n"; } mysqli_stmt_close($pstmt); } catch (mysqli_sql_exception $e) { // log exception } Kā arī tava fobija no objektiem arī ir steidzami jāārstē. OOP kods izskatās labāk: try { $pstmt = mysqli_prepare($link, 'SELECT col1, col2 FROM excel_online'); // $error = $pstmt->bind_param('s', $item['item_name']); $pstmt->execute(); $pstmt->bind_result($col1, $col2); while ($pstmt->fetch()) { echo "{$col1}, {$col2}\n"; } $pstmt->close(); } catch (mysqli_sql_exception $e) { // log exception }

Tu taču negribi teikt, ka izmanto real_escape, lai eskeipotu skaitļus? if (!ctype_digit("{$_GET['page']}")) { echo 'invalid page parameter value, fuck you'; }Mēs te nerunājam par cipara appendošanu pēc "LIMIT ", bet gan par manuālu jebkādu datu eskeipošanu. Tas, ka tu nevari izmantot parametrus iekš LIMIT, nenozīmē, ka tev automātiski neder prepared statements, tas ir absurdi. Es šo apeju citādāk - $stmt->where('WHERE name IN (?)', array('abc', 'def')). public function where($where, array $params = array()) { if (!empty($params)) { $where = str_replace( '?', substr(str_repeat('?,', count($params)), 0, -1), $where ); $this->params = array_merge($this->params, $params); } $this->wheres[] = $where; } $stmt->fetchAll(); public function fetchAll($some, $params) { // not exact code, just an example $this->stmt->prepare($this->getQuery()); $this->stmt->execute($this->params); return $this->stmt->fetchAll(); }Kveriju es modificēju, bet es neko neeskeipoju manuāli, tas darbs ir jādara db. In any case, izskatās, ka briest kārtējais holy war...

1) Tikai tāpēc, ka kveriju kešs kaut kādās situācijās nestrādā, nedrīkst pārslēgties uz hardkodētiem mysqli_real_escape_string(). +piekāst vecākas mysql versijas, time to move on. 2) Insignificant performance difference, ja vien vienā pieprasījumā neveic 1k+ pieprasījumus. 3) Kā tas jāsaprot - prepared statement nevar izmantot ... piemēram, LIMIT? Kas tieši tev aizliedz izmantot prepared statement ar šādu kveriju: "SELECT column FROM table WHERE time > :time ORDER BY column LIMIT 5" ? 4) Grūtāk debagojams, ja sūdīgi uzrakstīts kods, normālās aplikācijās exception izdod arī padotos parametrus. Jebkurā gadījumā, uztraukties par performance atšķirībām starp hardkodētiem mysqli_real_escape_string() un normāliem kverijiem ar prepared statementiem ir stulbi, protams, līdz brīdim, kad tu sāc rakstīt kaut ko, kam viennozīmīgi nevajadzētu būt rakstītam PHP. IMHO mysqli_real_escape_string() needs to die.

Kāpēc tu vispār izmanto mysqli_real_escape_string, nevis mysqli_prepare ar parametriem?

@OP - kāpēc pēdējā laikā cilvēkiem ir problēmas sakarīgi uzdot jautājumus?

@Kasspars - kādas tev problēmas ar valīdu HTML? @Klez - IE9+ vajag. Nevajag uzturēt arhaiskus pārlūkus, it sevišķi, ja tu neraksti kaut kādu aplikāciju priekš valdības.

Ctrl+F "?" 0 results close tab

........ // sort by keys, just in case $array1 = ksort($array1); $array2 = ksort($array2); if ($array1 === $array2) { return $array1; } if (strtotime($array1['created_at']) > strtotime($array2['created_at'])) { return $array1; } return $array2; Ja vajag, lai izvada abus masīvus, ja tie nav vienādi, tad šādi: if (strtotime($array1['created_at']) > strtotime($array2['created_at'])) { return array($array1, $array2); } return array($array2, $array1);

1. tas crawleris neparsē tālāk par pirmo lapu, ko es uzskatu par trūkumu. 2. http://pastebin.com/3ZbsbPKM ārkārtīgi elementāri, nesaprotu, kur problēma. Reāli aizņēma 2 minūtes, ne vairāk. Tur nevajag nekādus SelectorGadget, vienkārši skaties lapas HTML struktūru un domā loģiski. P.S. visus CSS selektorus hroma konsolē var notestēt šādi: 1) $('.newsList .item') 2) $('.newsList .item:first-child .title > a') etc. Te ir pārējie Developer Tools konsoles variabļi: https://developer.chrome.com/devtools/docs/commandline-api debug(functionName) liekas īpaši noderīgs.

No kurienes tu to ātrumu mēri un kur atrodas saits? Vajadzētu mērīt no pavisam citas lokācijas, piemēram, serveris kaut kādā datu centrā vai ofisā, bet mēri tu no mājām vai kādas kafejnīcas WiFi. Un tam, ka tu lieto "pusjēlu Windows mašīnu", requesta ātrumu nevajadzētu ietekmēt, tas var ietekmēt tikai datu apstrādi, saņemot response. Bet nu jebkurā gadījumā šī pieprasījuma laiks ir pilnībā atkarīgs no a) interneta pieslēguma ātruma (kā jau briedis minēja), izņemot gadījumu, kad lapa atrodas intranetā, un b) no paša skripta izpildes laika hosta pusē. Pārsvarā pie lēniem pieprasījumiem vainojams B.

Tu neizlasīji, ko es uz tavu pirmo postu atbildēju...

Anyway, es personīgi UNION neesmu nekad izmantojis (jeb varbūt vienu vienīgu reizi, bet vairs neatceros), un sastapies esmu burtiski kādas 3 reizes, tā kā negarantēju, ka manu kveriju nevar uzlabot, bet tam vajadzētu strādāt normāli.

SELECT field1, field2, created_at FROM Video WHERE user_id = :userid UNION SELECT field1, field2, created_at FROM Foto WHERE user_id = :userid UNION SELECT field1, field2, created_at FROM Blogs WHERE user_id = :userid ORDER BY created_at DESC Kaut kā tā. Bet tas strādās tikai tad, ja selektotie lauki ir vienādi visās 3 tabulās. Ja vajag un ir iespējams, pārsauc nepieciešamo lauku nosaukumus, lai ir vienādi starp visām 3 tabulām.

Nu par to gan nav ko brīnīties, bērniem kaut kāda velna pēc patīk extremely repetitive spēles. Man arī pirms gadiem desmit patika, tagad ne stundu nevaru tādas paspēlēt. BTW, kaut kad nesen pat iznāca MU 2, tā kā izskatās, ka tā spēle tik ātri nenosprāgs.

AJAX to the rescue. Nāksies mācīties arī javascript.

Neviens jau neteica, ka būt astotklasniekam ir slikti, vienkārši Kavacky nobrīnījās, ka čalis MU spēlē, un es pamanīju, ka viņam bookmarkos 8. klases viela stāv. Un tad sākās...

Kas ir, astotklasnieks neatbild, pārslēdzāt savu fokusu uz mani un tagad man dirsīsiet augumā visi, ja? Keyboard warriors...