slicer
-
Posts
43 -
Joined
-
Last visited
Everything posted by slicer
-
Sveicieni! Vai kādam ir pieredze darbā ar SQL Relay API? Ir vesela kaudze projektu, kas saprogrammēti uz PHP ADODB, lietojot persistent konekcijas. Vai būs jūtams ātrdarbības pieaugums ja MySQL native draiverus nomainīs uz SQL Relay. Jeb arī ir jēga programmēt jaunu, par ADODB vieglāku slāni, kas izliksies par ADODB, bet pamatos izmantos SQL Relay funkcijas? Jau iepriekš paldies par jebkuru viedokli!
-
A tev vajag atlasīt tikai tos ierakstus, kam status='necel' vai vajag atlasīt visus un, ja status = 'necel', tad "zvanit" lauka vērtības vietā atgriezt šodienas datumu? Vispārīgi kaut kā tā: SELECT *, IF (status='necel', now(), zvanit) AS zvanit FROM dati IF strādā vienkārši: IF (<nosacījums>, <true part>, <false part>)
-
Tāds gļuks vēl var rādīties, ja tu to failu 2x inklūdo. Pārskati arhitektūru.
-
Ja gribi valīdu kodu, izmano JS: <script type="text/javascript"> function setAlpha(obj, level) { obj.style.filter = "alpha(opactity="+level+")"; obj.style.opacity = level/100; } </script> <body> <img src="file://C:\Dokumenti\foto\test.jpg" onmouseover="setAlpha(this, 20);" onmouseout="setAlpha(this, 90);"/> </body> Tas tāds pliekans piemēriņš. Domāju, ka ideja skaidra un savām vajadzībām pratīsi pielāgot...
-
Mainīgo apstrāde pēc references lēnāka, nekā pēc vērtības (?)
slicer replied to slicer's topic in PHP un PHP :)
Hashsum no hashmap es atšķiru. Bet tagad ir putra. Delfīna hash updeitošanas direktīva ir no Zend dzinēja (zend_hash.c sourcefails). Ja jau, Delfīn, tu pats saki, ka tā ir hashmap update funkcija, tad ko viņa dara Zend dzinējā? Neesmu PHP eksperts, bet kaut kā no googlē salasītā konteksta nopratu, ka šī funkcija ir arī PHP dzinēja pamatā un strādā tieši ar PHP mainīgo hashmap. Un visu šo hash funkciju kopu var izmantot, lai pa tiešo manipulētu ar hashmap. Ir pat piemēri, kā has_update() var izmantot piemēram 700Mb liela faila satura iebakstīšanai pa tiešo hashmapā, neaiztiekot mainīgo instances. Par to, kas ir relatīvi pareizi un nepareizi. Nav nepareizi lietot pointerus, lai atvieglotu koda rakstīšanu (saīsinot ceļu pie kautkādagaraobjekta->apakšobjekta), taupītu atmiņu un paātrinātu procesu. Viss Windows ir uzrakstīts uz mēmiem pointeriem. Nu skaidrs - PHP references nav efektīvas un pointeru nav. Lieta slēgta. :) -
Mainīgo apstrāde pēc references lēnāka, nekā pēc vērtības (?)
slicer replied to slicer's topic in PHP un PHP :)
Jā. Principā tā ir hash_update() funkcijas realizācija no php_hash PECL. Ja daudz jāciklojas un datu apjoms apmaiņai šajos ciklos ir neliels, tad anyway nesanāks izdevīgi. Ok. Skaidrībā tikām. Paldies vēlreiz. P.S. Info: hash_update f-ju jau no dzimšanas var lietot PHP 5.1.2 lietotāji. Pārējiem tā jākabina klāt manuāli no šejienes: http://pecl.php.net/package/hash -
Mainīgo apstrāde pēc references lēnāka, nekā pēc vērtības (?)
slicer replied to slicer's topic in PHP un PHP :)
Tnx, Delfīn. Atradu arī PHP dokumentāciju par šo tēmu. Ja vēl kādam interesē: http://lv.php.net/references 4.4.0 -
Mainīgo apstrāde pēc references lēnāka, nekā pēc vērtības (?)
slicer posted a topic in PHP un PHP :)
Laikam jautājums tiem, kas PHP zina līdz pamatiem. Absurda situācija. Optimizējot ciklu, nonācu pie slēdziena, ka strādājot ar mainīgo referencēm iekš PHP (jeb līdzīgi kā tas ir C++ valodā ar pointeriem) ātruma ziņā tikai izbojā visu pasākumu. $t1 = microtime_float(); $searcher = new Searcher($pro, $order, $conn); $set = $searcher->Search(); while (!$set->EOF) { $pro = $set->fields; //šādi strādā ātrāk $pro = &$set->fields; //šādi strādā lēnāk ... //visādas darbības ar mainīgo $pro } $t2 = microtime_float(); echo $t2- $t1; //ķipa saliek pašreizējo laiku function microtime_float() { list($usec, $sec) = explode(" ", microtime()); return ((float)$usec + (float)$sec); } Kur prikols? -
Tev gadienā tas fails nav utf8 ar signatūru?
-
Krāniņu mērīšana!? :)
-
:)
-
Var izmantot, piem., GD bibliotēku. http://lv.php.net/gd
-
Kas attiecas uz SET NAMES klauzulu, tad tur tiešām laikam bija vienalga vai ir vai nav pēdiņas, lai gan, IMHO, MySQL dokumentācijā tiek rekomentēdas pēdiņas. jauninjais, tiešām pārbaudi tieši datu pareizību. iesaku uzlikt phpMyAdmin - ar to būs ļoti viegli to izdarīt.
-
sessijas kūkija piesaistīšana domēns.lv/direktorija
slicer replied to andrisp's topic in PHP un PHP :)
Sure! http://lv.php.net/manual/en/function.setcookie.php Izlasi par path parametru Ā vienīgi, lai piesietu sesiju pie direktorijas, laikam nāksies manuāli kūkijā uzsetot un savākt no tā sesijas id, katrrezi, kad mainās direktorija. Neesmu gan nekad neko tādu darījis tā, ka nezināšu tā konkrēti pateikt. Vispār iesaku neķēpāties šeit ar kūkijiem, bet sesijā uzveidot asoc. masīvu katrai no direktorijām un pāris elementāras funkcijas, kas tev uzsetos/atgriezīs tavus mainīgos no sesijas, atkarībā no direktorijas. Nu ceru, ka saprotami izteicos. -
Templātes atvieglo dzīvi viennozīmīgi, taču Smarty ir riebīgs monstrs. Tur ir par daudz viskā lieka. Es jau kurā projektā izmantoju ļoti vienkāršu templates klasi, kuras garums ir 300 rindiņas un esmu vairāk kā apmierināts (diemžēl nezinu, no kurienes tā klase ir cēlusies un nekāda nosaukuma tai arī isti nav. Vienk pirms kādiem 4 gadiem atklīda pie manis). Bet cik atceros no Smarty, tad visa tā padarīšana ar HTML'ā dzenamajiem IFiem un cikliem bija lieka, jo to visu var izdarīt ar vēl mazāku koda un templāšu parsēšana templātes iekš Smarty arī ir realizēta vienk. kretīniski.
-
Nu ja tik ļoti daudz ierakstu paredzēts, tad variants ar intervāliem strādās protams labāk un ātrāk, bet mazai, tabulai IMHO tas ir neefektīvi. Nu manis pēc...
-
Grey wolf - tagad parēķini savam BIGINT, cik atmiņas aizņems tabula un cik aizņems tabulas indekss uz order lauku, jo lai smuki varētu kārtot pēc order lauka, tādam tur būs noteikti jābūt :) BIGINT tādiem mērķiem nav paredzēts.
-
order lauks IMHO arī ir vispareizākā pieeja un jaunā ieraksta kārtas numurs ir jārēķina tieši ar MAX(order)+1. Ja liks pēc count() vērtības, tad vienā brīdīt tev būs 2 vienādas order vērtības (piem. pieliec vienu bildi, pieliec vēl vienu, tad vienu izdzēs kaut kur no sākuma un, kad liksi nākamo, tad pēdējām 2 būs vienādi order un tas nekam neder). Kārtošana arī nebūs tik sarežģīta - vienk. apmaini blakus stāvoši order lauku vērtības. Un par to iespraušanu vidū - intervāls nav slikti, bet intervāla vienmēr ar laiku izsīks. Vislabāk laikam būtu spraužot pa vidu vienk uztaisīt: UPDATE tabula `order`=`order`+1 WHERE `order` >= vēlamā_pozīcija #paceļam visu uz augšu no tās vietas, kur gribam iesprausties
-
MySQL Funkcija kas izdruka tabulas satura daudzumu
slicer replied to Mikus's topic in PHP un datubāzes
Vēl neliela piebilde, pirms ķeries pie skaitīšanas. Count funkcija neskaitīs ierakstu, ja norādītajā laukā būs NULL. Piemēram tu raksti: ... count(phone) ... un phone tev varētu būt tukšs, tad tos ierakstus, kur phone būs tukšs, count nesaskaitīs. Tādēļ labāk ir vienmēr lietot count(*) vai vismaz skaitīt pēc atslēgas lauka, ja tāds ir - pretējā gadījumā būs gļuki. -
Slinkuma pēc gan to tavu kodu neskatījos :) , bet ja kods ir ok, varbūt vienk. tam failam nav write tiesības (?)
-
Jā Turbas ir redzējušas :) Nu tur būs uz savi ~Ls200
-
sākot no Ls200 (firmā). Skatoties cik daudz informācijas, cik valodas vajadzīgas, vai ir nepieciešama satura vadības sistēma u.t.t. Cena var izaugt līdz ~400Ls. Firmā būs labums tāds, ka būs līgums ar garantijas periodu kā arī visas formālās lietas būs vienkāršākas. Protams paŗsvarā arī firmām ir atstrādāti web - saitu dzinēji un arī izstrāde notiks ātrāk, jo pie projketa strādās vismaz 2 cilvēki - dizaineris un programmētājs. Nu jā tāda www.gliemeznica.lv, kas dizaineri nav redzējusi, maksās Ls60, bet tad ja vajadzīga ir tāda lapa, tad ir jāgriež jautājums savādāk, nevis, ko gribam iegūt no izveidotās web-lapas, bet cik esam gatavi maksāt par web-lapu, lai tikai tā būtu. Skopais maxā 2x! ;)
-
Nu atsūti! Varbūt beidzot varēs kaut kur ātri redzēt sakarīgas prognozes...?
-
Nu un kur var apskatīties tavu laika ziņu lapu?
-
:) $fc = $wh->REPORT->TOWN->FORECAST[0]; pēc tam operācijas ar $fc analogi kā iepriekš.