DarkSide

Žēl, ka topiks nobeidzies. Vispār piedāvājums šķita diezgan interesants. Pats pagaidām vēl arvien strādāju valsts iestādē par "IT speciālistu" :) Zināšanas ar būtu, jo valsts iestādes, kas kaut vai minimāli nelietotu Oracle es nezinu. Pāris samērā lielus projektus uztaisījis esmu, tiesa gan vai nu ar Oracle+ASP vai arī MySQL+PHP, bet šķiet nav nekā vienkāršāka, kā taisīt kaut vai PHP+Oracle. Sākotnējais algas cipars ir nu daudzmaz ok (ja tas ir sākotnējais un ļoti drīz var pieaugt). Darba vieta gan paštruntīgi ka centrā - es jau cerēju, ka Bauskas ielā - tad būtu netālu no mājām un korķos nebūtu katru dienu jāsēž. Izglītība man arī vairāk kā atbilstu - LU maģistratūra datorzinībās :))) Neesmu gan 100% pārliecināts, ka gribu mainīt pašreizējo darbu - tā gan ir problēma. Vot ja būtu tie 1000Ls uz rokas, tad gan notiekti varētu par to padomāt.

Ja Tev tas x['aaa']++ ir iekš cikla, kas izpildās daudzas reizes un 'aaa' daudzreiz mainās, tad labāk šitā (jābūt ātrāk nedaudz): if(typeof(x['aaa']) === 'undefined') {x['aaa'] = 1;} else {x['aaa']++;} nevis if(typeof(x['aaa']) === 'undefined') {x['aaa'] = 0;} x['aaa']++;

Tā diemžēl nevaru darīt, jo iepriekš nezinu cik rindas būs jāiesprauž. To es uzzinu tikai tai brīdī kad veicu iespraušanu (pirms tam saņemot noteiktu datu rindu skaitu no servera izmantojot AJAX :) Tā tabula ir sakārtota pēc vienas no kolonnām, pēc kuras tad arī notiek "meklēšana" - klienta identifikatora. Userim tā tabula skrollējās uz leju - nu varbūt arī 30 ekrānus :) Tā tabula saucas "pārskats" un tāpēc tai zūd jēga, ja to sadala pa 30 atsevišķām lapām. Garajai, skrollējamajai tabula ir tas bonus, ka var ļoti ātri pabraukājot uz leju un augšu pārskatīt visus klientus (kopējo stāvokli) un ja rodas interese par kādu konkrētu, tad var atvērt tā klienta pasūtījumus, pieprasot datus no servera un iespraužot rindas kā tas minēts iepriekš...

Paldies par linkiem - nočekošu rīt.

Hmm, vispār ideja interesanta, bet ir viens BET - tai iekšējā tabulā vajag visas kolonnas tieši tādā pašā platumā kā parent table, lai useris nemaz nenojauš, ka tā reāli ir cita tabula. Laikam jau to var noorganizēt ar JavaScript katrai kolonnai iebakstot precīzu cell.width (vai kautkā tā) no parent.table...

Droši vien tas saistīts ar ātrdarbību, jo browserim tad viss DIVs ir jāievieto weblapā vienā reizē, nevis jāievieto katrs elements atsevisķi.

Tas nav iespējams - uz IE nestrādā un punkts (slinkums tagad meklēt linku no Microsoft lapas, kur tas bija aprakstīts). Ideja tāda, ka IE nestrādā innerHTML uz <table>, <tr> un vēl dažiem tagiem. Uz <td> gan strādā un to arī izmantoju, bet problēma ir tieši ar to kā ātri ielikt jaunas rindas tabulā. Varianti cik saprotu ir tikai divi - insertRow vai DOM metodes (appendChild). Nav jau briesmīgi sarežģīti, bet ķēpa sanāk ar to, ka tās iespraustās rindas TD elementos iekšā vēl ir SPAN, TEXT un vēl šis tas - teorētiski ar laiku var'but pat formu input elementi. Tad tie visi sanāk taisīt ar createElement un tā jau ir lielāka ķēpa nekā vienkārši nomainīt TD elementam innerHTML. To varētu darīt, bet tas būtu samērā slikts variants, jo man ir nepieciešama liela, gara tabula, kur pēc savas būtības ir liels pārskats (tās daudzās kolonnas ir kalendāra dienas). Tādēļ ir svarīgi, lai useris varētu vienkārši paskrollējot tabulu uzreiz vizuāli redzēt kopējo situāciju pa visām rindām nevis lēkāt pa lapaspusēm.

Sveiki! Sen neesmu neko rakstījis, bet tad pēkšņi atcerējos, ka ir taču tāds php.lv forums! :) Tad nu lūk kāda man problēma - varbūt Jums ir kādas idejas vai varbūt jau gatavs risinājums. Tātad ir HTML tabula (samērā liela - teiksim 2000 rindas, 50 kolonnas). Vienkāršības labad uzskatīsim, ka tie ir dati par kautkādiem klientiem. Katrā no šīm rindiņām pirmajā kolonnā ir "+" bildīte uz ko nospiežot ielādējas un parādās konkrētā klienta veikto pasūtījumu saraksts (izmantoju AJAX gudrības šo datu iegūšanā). Šis pasūtījumu datu saraksts parādās kā papildus iespraustas tabulas rindiņas zem konkrētā klienta. Katram klientam ir apmēram 1-10 pasūtījumu, parasti ne vairāk. Viss jau būtu baigi smuki utt. viss strādā, taču ir viena baigi nepatīkamā problēma. Es tās jaunās rindas tabulas vidū iespraužu ar JavaScript insertRow un insertCell palīdzību, kas kā izrādās nezkādēļ strādā baigi lēni, ja tabula ir tik liela (2000x50 piemēram). Līdz ar to viss pārējais softs šansē zibenīgi, bet IE kamēr iesprauž tās 1-10 rindiņas kautkur HTML tabulai pa vidu paiet gandrīz 5-10sek, kas ir galīgi garām. Tad nu lūk jautājums, vai ir kāds variants vai kas cits, kā paātrināt papildus rindiņu iespraušanu samērā lielā HTML tabulā ar JavaScript. Zinu, ka varētu vēl mēģināt ar DOM metodēm (appendChild utt...), bet kautkā negribas ķēpāties - vai tas būtu to vērts pārtaisīt insertRow uz appendChild utml.? Jau iepriekš paldies par palīdzību!

setTimeout laiks jānorāda milisekundēs šķiet bija nevis sekundēs. Respektīvi 1000 = 1 sekunde. Ja ieliksi vienkārši 1 tas nozīmēs 1/1000 sekundes, ko loģiski kompis droši vien nespēs sagremot un sajuks prātā :)

Nu bāc! Tak ieliec kādu atdalītāju - piemēram, "\n" (new line) pirms pievieno jaunus datus failā. Vēl labāk: if (fails_eksistē) { failam_pievienot_datus ("\n"); } fails_pievienot_datus (textarea_dati);

Vai tiešām nevienam nav nekādu ideju? :(

Sveiki! Vajag nelielu palīdzību. CSS Kods sekojošs: .comboboxis { font-family: Verdana, Arial; font-size: 9px; height: 12px; background-color: papayawhip; } Problēma tāda, ka IE6 tas forši strādāja - augstums pastiepās lielāks = ar comboboxī esošā teksta augstumu. Diemžēl jaunajā IE7 combobokša augstums paliek tiešām tie 12px un līdz ar to tekstam var redzēt tikai augšiņu :) Cik atradu internetā, tad IE7 izmanto kautkādus min-height max-height, taču pat ar tiem kautkā negrib strādāt. Pie tam man vajadzētu CSS stilus tādus, lai strādā gan uz IE6 gan uz IE7 korekti. Vai ir kādas idejas?

Man tāda pati problēma. Lietoju visur UTF8 kodējumu, un dažus latviešu burtus MySQL atšķir no parastajiem, bet dažus nē... Problēmu neesmu vēl atrisinājis, jo iestāstīju klientam, ka tā ir mana projekta fīča nevis bugs :)))

Tāds man bija pats pirmais variants, kādu iesākumā biju uzkodējis. Baigi forši var DB serveri sēdināt ar ~16'000 selectiem kādu 10-20sek laikā :) Kautkā tas Postgre mani neaizķēra. Biju uzinstalējis, neko nemācēju izdarīt (neesmu jau galīgs iesācējs, bet...) un tik pat ātri noinstalēju nost :) Zinu kas ir CPU cost, taču vai kautkur ir pieejams freeware kautkāds zofts, kas analizētu MySQLa selectus? Vienīgais, ko šad tad ir gadījies izmantot ir EXPLAIN SELECT... un tas nedod CPU cost, bet gan tikai dažus parametrus, kuru tabulu ar kuru salinko un kādus indeksus izmantos, bet CPU cost kā tādu acīmredzot MySQL nemaz nerēķina?

Vot, vot - paskatījos iekš tā iepostotā linka - nav vērts ķēpāties. Pagaidām izskatās, ka MySQL stored procedures vēl arvien ir tikai lieka laika tērēšana un ķēpa.By the way - kāda ir pieredze darbā ar šādu komplektu: Windows+Apache2+PHP5+Oracle10g? Oracle10g man šķiet arī izlaida freeware produktu ar kautkādiem ierobežojumiem (šķiet <2Gb datubāzes izmērs vai kautkas tāds), varbūt nākotnē tomēr tādus nopietnākus projektus taisīt uz Oracle nevis MySQL bāzēm? Kā PHP ar Oracle sadzīvo?

Vēl viens patups jautājums par MySQL (offtopic šeit, bet saistīts ar iepriekš runāto). Es lietoju MySQL 5.x un MyISAM datubāzi. MyISAM cik saprotu nevar veidot datubāzes funkcijas un procedūras. MySQLam bija vairāki tie datubāzes veidi un kādā no tiem šķiet varēja taisīt built-in funkcijas, procedūras, trigerus utml. Tātad jautājums ir - kā saucās tas MySQL 5.x datubāzes veids un vai kāds no Jums to lieto. Ideja vienkārša - varbūt visu to parsēšanu un kopsummu gatavošanu utt. uztaisīt kā MySQL procedūru, kas atgriež pilnībā noformatētu HTML tabli rezultātā uz PHP un viss. Līdzīgu variantu esmu taisījis vienam citam projektam ar IIS,ASP,Oracle - šansē tīri labi - ASP padod Oracle funkcijai tikai atlases parametrus un Oracle funkcija jau atgriež atpakaļ pilnībā noformatētu HTML tabli kā stringu (Oraclē CLOBu). + Jautājums - kā un vai iespējams būtu šai gadījumā pārkonvertēt datus no MySQL MyISAM uz MySQL xxxx?

1) nav tik būtiski, vienkārši domāju, lai es visus is_deleted nosacījumus varu izvākt no WHERE, lai smukāk izskatās - bet nu pofig. 2,3) Nu es jau to arī tāpēc daru ar PHP ar tiem nežēlīgajiem foreachiem. Par memory_limit, man uz izstrādes vides (Win+Apache+PHP4) memory_limit=8M un viss izgriežas (pat ja Apache process TaskManager var redzēt, ka noēd brīžiem 200Mb RAM), bet uz produkcijas vides (Linux+Apache+PHP4) memory_limit=50M un procesi kas apēd vairāk par ~50Mb RAM neizgriežas... Kā tā var būt? Vai tiešām sanāk tā, ka Windows tas PHP parametrs ir pie pak..ļas, bet Linuxam nē???

Hmm - doma jau vispār laba - taisīt tā, lai selekc uzreiz jau atgriež HTML tables rindiņas, taču kā tādu selektu uzrakstīt, ja atskaites struktūra ir diezgan, teiksim tā, īpatnēja. Lūk, piemērs: 1) Ir tables CONTRACT (cid,cname), ORDERS(oid,cid,oname), WORKS(wid,oid,wname). 2) Selekta princips varētu būt apmēram tāds (jālieto LEFT JOIN): SELECT c.cname, o.oname, w.wname FROM contract c LEFT JOIN orders o ON (c.cid=o.cid AND o.is_deleted='F') LEFT JOIN works w ON (o.oid=w.oid AND w.is_deleted='F') WHERE c.is_deleted='F' 3) Nepieciešamā rezultāta tabula: CNAME | ONAME | WNAME --------+--------+-------- ccc_1 | ooo_11 | www_111 --------+--------+-------- | | www_112 --------+--------+-------- ccc_2 | ooo_21 | --------+--------+-------- ccc_3 | | --------+--------+-------- ccc_4 | ooo_41 | www_411 --------+--------+-------- | | www_412 --------+--------+-------- | ooo_42 | www_421 --------+--------+-------- totals: ................... Jautājumi: 1) Vai WHERE c.is_deleted='F' nevar kautkā arī pārcelt pie FROM nemainot selekta ideju, līdzīgi kā o.is_deleted vai w.is_deleted? 2) Rezultāta tabulā mēģināju attēlot praktiski visus iespējamos variantus, man kautkā nav ideju kā pārrakstīt šo selektu tā, lai iegūtu tādu rezultāta tabulu (ideja ir tā, ka piemēram ccc_1 parādās tikai 1.rindiņā un tālākajās saistītajās rindiņās to vairs neatkārto, līdzīgi arī ar ooo utt...) Oracle Query Builder ir tāda funkcija BREAK, kas dara ko līdzīgu, bet kā kautko tādu uzrakstīt iekš MySQL ar vienu SELECTu netieku gudrs. 3) Vēl dažām kolonnām derētu totals apakšā? To gan laikam ar to vienu selectu nevarēs dabūt. Plus vēl ir dažas atskaites vēl kreetīniskākas, kur vajag arī subtotals pa grupām (piemēram, subtotals zem ccc_1 grupas).

:) Žēl, ka te forumā nav tā kā dažās citās vietās, kad var dot punktus par labu atbildi uz jautājumu... :)

Projekts nopietns un jau ~ gadu tiek lietots in real life. Problēma tur, ka pa šo gadu ir saradies vairāk datu nekā sākotnēji tika prognozēts. Problēma ar lielo aizņemto atmiņas daudzumu rodas uz webservera uz kura griežas šis projekts. Webserveris ir Linux+Apache un kautkāda man nesaprotama iemesla dēļ Apache acīmredzot nokillo procesus, kas aizņem vairāk par apmēram 50Mb RAM. Itkā webservera admini dievojās, ka nekas tāds navētu būt un nekādu ierobežojumu Apache servisam uz webservera nav uzlikti, bet anyway - rezultāts ir viens - "Zero sized replay" vai arī "Page can't be found". Ikdienas darbā šādas konstrukcijas protams netiek izmantotas un ikdienā strādājot (datu ievade, meklēšana, labošana utt.) ar projektu viss ir ok. Šādi brīnumaini masīvi man sanāk lietot veidojot tādas lielākas atskaites par ilgākiem laika periodiem. Tur sanāk daudz datu, kas tiek pieprasīti no MySQL un atgrieztais resultset pēc tam tiek ieparsēts strukturētā masīvā (manā piemērā $arrData), kas pēc tam ar šiem cikliem tiek sakārtots, pārkārtots, saskaitītas visādas starpsummas utt. un ieparsēts objektā, kas satur 2-dimensiju masīvu + dažas definīcijas (piemēram, colspan, rowspan utt), kas savukārt ir tas masīvs no kura tiek noģenerēta un atgriezta HTML tabula (faktiski HTML&bonusi, lai var ielasīt Excelī). Problēma sanāk ar to, ka atlasāmie dati mazāk nekādā gadījumā nepaliks - paliks tikai vairāk, līdz ar to visa tā apstrāde ir jāpārtaisa tā, lai nerītu tik daudz atmiņas, jo 200Mb tikai vienai atskaitei tas nav maz :( PHP5 diemžēl šobrīd lietot nevaru, jo prasība ir lai viss griežas uz PHP4. Varbūt ar laiku arī nāksies uz PHP5 pāriet, bet tad vajadzēs pārkodēt un testēt stipri daudz ko (a projekts nav mazais) - it sevišķi visu kas darbojas ar objektiem (PHP5 piemēram ir funkcija clone(), savukārt PHP4 noklonēt objektus varēja ar vienkāršu obj1=obj2).

V3rb0 - Tu esi glābējs :) on(B.a_id=A.id and B.default=1) iespēju kautkā biju manuālī palaidis garām un nomocījos gandrīz visu dienu :) Paldies!

Hmm.... sadalīt to ciklu es nevaru, jo tas echo tur ir tikai kā piemērs, īstenībā ir bišķi sarežģītāk... Visu kodu te nelikšu - sanāks pārāk gari...BET viena ideja man radās, anyway šitie foreachi apēd kādus 100Mb, bet otri 100Mb rodas pēc šiem foreachiem, kad izmantojot to $row_id (tāpēc itkā bremzēja ifs, jo row_id palika stipri lielāks nekā bez tā ifa) es pēc tam ģenerēju izdrukas tabulu. Savukārt, šī izdrukas tabula ir objekts, kas acīmredzot uz PHP4 kautkā gļukaini norij RAMu. Statistika - izdrukas tabulas objekts strlen(serialize(objekc)) = ~9Mb, bet tad es to tabulu "normalizēju", respektīvi aizpildu tukšās celles, sakārtoju colspanus utml. un pēc tās "normalizēšanas" izdrukas tabulas objekts jau aizņem strlen(serialize(objekc)) = ~17Mb... Ja pieņemam, ka PHP4 kautko vēl ar objektiem nogļuči, tad varbūt var arī sanākt tie apmēram 100Mb... :( Vienvārdsakot, paēdīšu "pusdienas" un izpētīšu līdz galam. Tad jau došu ziņu ko jaunu būšu noskaidrojis :) Paldies Jums!

Šitais variants nekādu lielo ieguvumu nedod (varbūt pāris Mb) - skat.zemāk ko atradu... each() līdzīgi kā ar array_keys - nekāds lielais ieguvums (varbūt pāris nepamanāmi Mb). Skat.zemāk... Lūk ko atradu - tikai to nu es vēl vairāk nesaprotu :-) Lūk nedaudz papildināts mans kods(skatīt to $first_row): $row_id = 0; foreach($arrData['DEPARTMENTS'] as $did=>$dvalue) { foreach($dvalue['CONTRACTS'] as $cid=>$cvalue) { $first_row = true; foreach($cvalue['ORDERS'] as $oid=>$ovalue) { if($first_row) $first_row=false; else $row_id++; echo "$row_id, $did, $cid, $oid"; } } } Tas gan arī nav pilnīgi viss kods, bet pati sāls tur ir. Tad nu lūk, līdzko es izkomentēju ārā to rindiņu if($first_row) $first_row=false; else $row_id++;, tā Apache vairs apēd nevis 200Mb RAM bet gan tikai 100Mb. Vot tas jau man pavisam nepielec. Sanāk, ka problēma bija ne tik daudz tajos foreachos, bet gan ar kautkādu IFu??? Sviests. Kādas idejas?

Pat ja būtu visprastākā kopija - nu labi - tad 2x paņemtu RAM, bet struktūra ir uz apmēram 10Mb nevis 100Mb. Laikam man rokas līkas, bet foreach($array as $key => &$value) man nešansē. Piesienas pie &. Kurā brīdī Tu domāji tās references izmantot?

Daži parametri: strlen(serialize($arrData)) = ~10'000'000 tas ir apmēram 10Mb. Grozies kā gribi, pat ja foreach patiešām būtu pilnīgi garām un taisītu 10 kopijas no pilnīgi visa $arrData tad tik un tā nesanāktu ~200Mb. Saskaitīju kopā ar šo pašu funkciju strlen(serialize($foo)) pilnīgi visus mainīgos kas izmantoti šais foreachos un tik un tā sanāca kopā apmēram 25'000'000 jeb 25Mb... P.S. Tur nav objektu - tas ir pliks masīvs tikai ar samērā dziļu struktūru. un foreachi īstenībā ir 5 gab. nevis 3 kā parādīju piemērā. Departments kādi 10-20, Contracts kādi 1000-5000, Orders arī +/- tikpat cik Contracts