Maris-S

Codez, paldies par skaidrojumiem. Vienīgi nesanāk izprast līdz galam. Nav gadījumā kļūda šajā vaicājumā? SELECT * FROM ips WHERE `from`<=$ip ORDER BY `from` LIMIT 1 Vai nevajadzētu zīmei <= būt uz otru pusi? SELECT * FROM ips WHERE `from`>=$ip ORDER BY `from` LIMIT 1 It kā loģiku es sapratu, ja neskaita to zīmi uz kuru pusi viņu likt. Ar joinu manējo vaicājumu nesanāca sataisīt, tāpēc sataisīju to šādā veidā: select sql_no_cache a.ip, (select `name` from iptocountry where fromaddr >= inet_aton(a.ip) order by fromaddr limit 1) from ip_addresses a Te zīme ir jau pamainīta, ja ieliek tur <= tad protams viņš momentā izpildās (ja ir indekss), bet rezultāts ir nepareizs, jo katru reizi tiek atgriezts pirmais ieraksts, kā tam arī jābūt. Vaicājums izpildās ļoti lēnu, jau kādas 30 minūtes un rezultāta nav. Apstādināju vaicājumu un paskatījos kādi ir pirmie rezultāti, izrādījās ka nav pareizi. Parunāju par šo lietu ar kolēģi un pēc viņa domām šādam vaicājumam sākumā izpildīsies where un tikai tad tiks veikta kārtošana, būtībā pēc iegūtiem rezultātiem tā tas patiešām arī varētu būt. Sataisīju arī atsevišķu vaicājumu lai pārbaudītu cik pareizi strādā: select `name` from iptocountry where fromaddr >= inet_aton('24.100.14.0') order by fromaddr limit 1 Rezultāts tomēr nav pareizs, protams arī ar <= nestrādā pareizi, bet nu tas ir saprotami. Atgriež Kanādu, bet jābūt United States. Ko es īsti neesmu sapratis?

Nu arī neoptimizētais variants izpildījās. Ar to sanāca 6720.030 sekundes.

Es arī pamēģināju noteikt valstis lielajam ip adrešu sarakstam, ar optimizēto pieeju izpildijās ~1.07 sekundēs, bez optimizācijas jau kādu pus stundu vaicājums notiek, vēl nav izpildījies.

Skatos diskusija šeit jau arī ir pagājusi uz priekšu. Izveidoju jaunu tēmu par valsts noteikšanas pēc ip adreses, tā kā šajā tēmā primāri ir mazliet kaut kas cits, tad pašas valsts noteikšana varētu tikt apspriesta šeit: http://php.lv/f/topic/17689-valsts-noteiksana-pec-ip-adreses-optimizeta-pieeja kam interesē protams.

Tātad sakarā ar šo: http://php.lv/f/topic/17678-ko-jus-sakat-par-sadu-lietu nolēmu pa saviem seniem materiāliem atrast valsts noteikšanas pēc ip adreses optimizāciju. Uzreiz jāpiebilst ka šādu lietu taisīt ir aktuāli kad valsti jānosaka ļoti bieži vai uzreiz jānosaka valsti vairākām ip adresēm, tad optimizācija būs jūtama ar neapbruņotu aci. Principā optimizācija paātrina vaicājumu izpildi pat vairākus desmitus reizes, bet nu tas protams atkarīgs arī no procesora ātruma utt. Vēl varētu piebilst ka šī optimizācija nebūs tik ātra kā taisīt dll/so MySqlam ar funkciju kas no sakārtota masīva meklēs valsti pēc binārās meklēšanas algoritma, bet tomēr šo optimizāciju var izmantot uz jebkura servera, jo nevajadzēs neko papildus instalēt, jo būs izmantotas tikai MySql iespējas. Vēl viena lieta, kas ir uzreiz jāpiezīmē, tā ir datubāzes izmēra palielināšanās, tabula iptocountry būs lielāka, bet ņemot vērā mūsdienu datu nesēju ietilpības un serveru nomas cenas, to diez vai kāds pamanīs. Ideja ņemta šķiet no šejienes (jau neatceros): http://ip-to-country.webhosting.info/node/view/384 un pārtaisīta, lai varētu ģenerēt jaunu tabulu tikai ar sql. Uzreiz atvainojos ka viss kods ir šeit un sanāk diezgan garš rakstiņš. Tātad sāksim ar iptocountry datubāzi. To neaprakstīšu kā dabūt un kā csv ieimportēt pašā datubāzes tabulā, to domāju katrs varēs paveikt paša spēkiem. Vienīgi piebildīšu ka es šo tabulu nosaucu par iptocountry un tai ir sekojoši lauki: CREATE TABLE `iptocountry` ( `fromip` varchar(15) COLLATE utf8_bin NOT NULL, `toip` varchar(15) COLLATE utf8_bin NOT NULL, `fromaddr` int(10) unsigned NOT NULL, `toaddr` int(10) unsigned NOT NULL, `code` varchar(2) COLLATE utf8_bin NOT NULL, `name` varchar(128) COLLATE utf8_bin NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin Tātad šajā tabulā arī importējam visus ip un valstu datus. Galvenā ideja ir ļaut MySql izmantot indeksus, ko man šķiet viņš nevar izdarīt ar operācijām lielāks mazāks (>, <). Tādai optimizācijai mums būs nepieciešama klāt vēl viena kolona, es to nosaukšu bit, kas saturēs pirmos bitus ip adreses skaitliskajām vērtībām. Šajā piemērā es ņēmu tieši 15 bitus. Ko vairāk bitu to ātrāk būtu jāstrādā, bet būs lielāka tabula, jo būs vairāk papildus ieraksti. Tātad šajā gadījumā tabulai jābūt datiem saliktiem tā, lai viena apgabala (vienas rindiņas) fromaddr un toaddr pirmie 15 biti būtu vienādi, t.i. kur šis apgabals ir pārāk liels un toaddr pirmie 15 biti atšķirsies no fromaddr būs jādala divās vai vairākās rindiņās. Koloniņai bit obligāti jātaisa indekss. Kā jau no šī visa var noprast tad meklēšana sākumā tiks veikta bit koloniņā, izmantojot indeksu, tad tiks salīdzināti fromaddr un toaddr ar parasto lielāks un mazāks (>= un <=) vai arī between, kā kuram patīk. Tātad sākumā izveidosim tabulu, kurā ievietosim iptocountry tabulas vērtībām, sadalot lielos apgabalus mazākos, kur nepieciešams, nosaukšu šo tabulu par iptocountry_15: CREATE TABLE `iptocountry_15` ( `bit` int(10) unsigned NOT NULL, `fromip` varchar(15) COLLATE utf8_bin NOT NULL, `toip` varchar(15) COLLATE utf8_bin NOT NULL, `fromaddr` int(10) unsigned NOT NULL, `toaddr` int(10) unsigned NOT NULL, `code` varchar(2) COLLATE utf8_bin NOT NULL, `name` varchar(128) COLLATE utf8_bin NOT NULL, KEY `I_bit` (`bit`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin Tagad, lai sadalītu lielākos apgabalus būs nepieciešama vēl viena tabuliņa, kas saturēs vienu koloniņu un tiks aizpildīta vienkārši ar veseliem skaitļiem, tabula numbers_15: CREATE TABLE `numbers_15` ( `number` int(10) unsigned NOT NULL, PRIMARY KEY (`number`) ) ENGINE=MyISAM AUTO_INCREMENT=113665 DEFAULT CHARSET=utf8 COLLATE=utf8_bin Izveidojam procedūru, kas aizpildīs tabulu ar veseliem skaitļiem, procedūra arī noteiks mazāko un lielāko vērtību, ko tur ir jāieliek. CREATE PROCEDURE generate_numbers() BEGIN declare F int; declare T int; declare nr int; set F = (SELECT MIN(fromaddr>>15) FROM iptocountry); set T = (SELECT MAX(toaddr>>15) FROM iptocountry); set nr = F; WHILE (nr >= F) and (nr <= T) DO INSERT into numbers_15 VALUES (nr); SET nr = nr + 1; END WHILE; END Palaižam procedūru un tā aizpildīs tabulu numbers_15 ar vajadzīgām vērtībām. Ņemiet vērā ka sākumā man procedūras palaišana izdeva dīvainu kļūdu, nekur viņu nepierakstīju, bet līdzēja thread_stack mainīgā palielināšana uz 180K my.ini failā. Man liekās ka šī vērtība atkarīga instalācijas sākotnējās konfigurācijas laikā. Tagad kad ir aizpildīta tabula ar numuriem, mēs varam izveidot jauno iptocountry_15 tabulu, izmantojot numbers_15. insert into iptocountry_15 select fromaddr>>15 bit, fromip, toip, fromaddr, toaddr, code, `name` from iptocountry where fromaddr>>15 = toaddr>>15 union select b.number bit, if (a.fromaddr>b.number<<15, inet_ntoa(a.fromaddr), inet_ntoa(b.number<<15)) fromip, if (a.toaddr<((b.number+1)<<15)-1, inet_ntoa(a.toaddr), inet_ntoa(((b.number+1)<<15)-1)) toip, if (a.fromaddr>b.number<<15, a.fromaddr, b.number<<15) fromaddr, if (a.toaddr<((b.number+1)<<15)-1, a.toaddr, ((b.number+1)<<15)-1) toaddr, a.code, a.`name` from iptocountry a, numbers_15 b where fromaddr>>15 <> toaddr>>15 and b.number between (a.fromaddr>>15) and (a.toaddr>>15) order by fromaddr Šīs lietas izpildās ne visai ātri uz lēnākiem datoriem. Tagad mums ir jauna tabula iptocountry_15, kurai pirmā kolona bit noderēs, lai izmantotu indeksu vaicājumos. Pārbaudei izveidosim jaunu tabulu ar vienu kolonu, kas saturēs dažādas ip adreses. Es tās paņēmu no šīs lapas: http://www.ipspotting.com un saliku tās tabulā, kopā 50 ip adreses. CREATE TABLE `ip_addresses` ( `ip` varchar(15) COLLATE utf8_bin NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin Sākumā izmantosim standarta vaicājumu ar tabulu iptocountry, bez optimizēšanas. Tātad veidojam vaicājumu, kas nosaka valsti, visām tabulā ievietotajām ip adresēm, tātad jānosaka 50 valstis. select sql_no_cache a.ip, b.name from ip_addresses a left join iptocountry b on inet_aton(a.ip) between b.fromaddr and b.toaddr Vaicājuma izpildes laiks 17.902 sekundes. Diezgan ilgi. Tagad darām to pašu, tikai izmantojot bit tabulā iptocountry_15. select sql_no_cache a.ip, b.name from ip_addresses a left join iptocountry_15 b on b.bit = inet_aton(a.ip) >> 15 and inet_aton(a.ip) between b.fromaddr and b.toaddr Vaicājuma izpildes laiks 0.001 sekunde. Principā par ātru sanāca, cik atceros pirmo reizi kad šo izmēģināju uz mazāk jaudīga datora panāk izpildes laiku sekundes desmit tūkstošajās daļās nesanāca. Visu šo sarakstīju pēc materiāliem, kurus labu laiku nepētīju, tāpēc ceru ka nekur nekļūdījos, bet pēc abu vaicājumu rezultātiem izskatās ka strādā pareizi, tāpēc ja pamanāt kļūdas, kam būs pacietība pētīt, rakstiet.

Tā kā Aleksejs ieminējās to, ka valsts noteikšana pēc ip adreses prasa daudz resursus, par ko viņam arī ir pilnīga taisnība, tad atcerējos vienu labu lietu kas šo padarīšanu var ļoti spēcīgi optimizēt. Tā kā rakstīšana un vaicājumi būs diezgan gari, tad izveidošu jaunu tēmu sadaļā datubāzēm, pēc tam ielikšu arī šeit saiti.

Es pārbaudīju Ginta variantu ar group_concat un viss tur strādā. Man tāda lieta arī ir mazliet aktuāla. Vienīgi nepatīk ka group_concat ir ierobežojums, kas dažreiz varēs izpausties pie konstrukcijām ar ļoti lielu dziļumu. To protams var labot ar MySql group_concat_max_len mainīgā palīdzību, bet jebkurā gadījumā nevar zināt cik dziļi koks tiks sataisīts sistēmas izmantošanas laikā, jo tādi modeļi paredz tieši neierobežotu dziļumu.

Domāju, ja īpaši neder gatavi risinājumi, var mēģināt taisīt cms patstāvīgi. Tās lapas neizskatās pārāk sarežģītas. Vienā no lapām uz ātro pamanīju ka ir forums, to gan labāk likt kā gatavu risinājumu. Vismaz es tā darītu, ja pieejamie cms nederētu. Tātad lapa patstāvīgi, forumu paņemt kādu no gataviem.

Par hierarhiskām datu struktūrām šeit ir redzēti daži jautājumi, bet paskaties šeit: http://dev.mysql.com/tech-resources/articles/hierarchical-data.html Tev jāskatās pirmais variants ar parrent id. Tā virspusēji sistēma ir tāda ka Tu dabū datus no datubāzes un rekursīvi izej tiem cauri veidojot galeriju un apakšgaleriju attēlošanu, kā tiks veidota atkāpīte jau paliek Tavā ziņā, vai vai ar css norādīts attālums utt.

Bubu, šoreiz laikam Tev ir tikai daļēja taisnība. Pilnīgi jebkura diskusija var izvērsties personiskos aizvainojumos, kas šeit ir ne reizi vien pierādījies, bet to nu nekādi nevajadzētu uzskatīt par iemeslu, lai liegtu foruma dalībniekiem diskutēt par darba atalgojumu. Ne tikai algas jautājums ir iemesls rupjībām un foruma noteikumos ir skaidri un gaiši pateikts rupjības un aizvainojumi ir aizliegti, to arī jāievēro, nevis jāliek prioritātes kuros jautājumos rupjības būs sodītas bargāk un kuros tiks palaistas gar ausīm. Pareizi būtu atļaut diskusijas par darba atalgojumiem un rupjības un nepamatotus aizvainojumus dzēst ārā un ja nelīdz tad nobanot. Tā ir pilnīgi normāla pieeja visām foruma sadaļām, kāpēc kādai vienai jātaisa izņēmumi? Es protams saprotu ka darba devēji negrib runāt par atalgojumiem publiski un arī darba vietās bieži vien aizliedz ar līgumu apspriest algas ar kolēģiem, iemesls ir viens, lai varētu pēc iespējas mazāk maksāt darbiniekiem. Tomēr būtu pareizāk samaksu noteikt pēc zināšanām un pienākumu apjoma, Kā jau šeit izteicās atalgojuma diapazons pret prasību diapazonu, ja kādi studenti pretendēs uz lielāko ciparu bez atbilstošām zināšanām un pieredzes, tad tā jau ir vairāk viņu problēma, darba devējam ir jāprot paskaidrot kas darbiniekam nepietiek lai viņš varētu vairāk pelnīt (nevis saņemt, bet pelnīt), ja viņš arī pēc tam nesaprot, tad iespējams tā arī nevarēs iederēties konkrētajā sfērā un tā jau ir viņa paša problēma. Protams nevar nevienu piespiest rakstīt algu darba sludinājumā un to nav jādara, bet liegt diskusijas šajā sakarā, kā jau minēja, ir netaisnīgi pret foruma dalībniekiem.

Ja ir vēlēšanās paskatīties cik kāds process izmanto tīklu reālajā laikā, tad varētu izmantot: nethogs.

Taisi atsevišķu tabulu ar laukiem "user_id" un "article_id", ievieto atbilstoši ierakstu kad lietotājs atver rakstu, ja ir tāds ieraksts, tad raksts ir izlasīts.

Nē, domāju gan labāk izmantot php iebūvētās iespējas tādām pārbaudēm.

Tīri intereses pēc paskatījos kāda ir ātrdarbība un arī cik pareizi strādā. Kemito piedāvāto izteiksmi gan nācās nomainīt jo patiešām Briedis norādītos e-pasta variantus apstrādāja nekorekti, izteiksmi paņēmu no php.net komentāriem funkcijai preg_match. Interesanti tas ka preg_match strādā ātrāk, kaut gan sākumā domāju ka būs otrādāk. Tātad ātruma pārbaude: <?php error_reporting(E_ALL); ini_set('display_errors', 'on'); /** * Simple function to replicate PHP 5 behaviour */ function microtime_float() { list($usec, $sec) = explode(" ", microtime()); return ((float)$usec + (float)$sec); } function validMail($email){ return (bool)filter_var($email, FILTER_VALIDATE_EMAIL); } function validMail2($email) { return (bool)preg_match('/^([a-z0-9])(([-a-z0-9._])*([a-z0-9]))*\@([a-z0-9])(([a-z0-9-])*([a-z0-9]))+' . '(\.([a-z0-9])([-a-z0-9_-])?([a-z0-9])+)+$/i', $email); } ?> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Mail</title> </head> <body> <?php set_time_limit(0); $c = 10000; $email = "[email protected]"; $time_start = microtime_float(); for ($i = 0; $i < $c; $i++) validMail($email); $time_end = microtime_float(); echo '<p>Filter_var izpildes laiks: '.($time_end - $time_start).' sekundes.</p>'; $time_start = microtime_float(); for ($i = 0; $i < $c; $i++) validMail2($email); $time_end = microtime_float(); echo '<p>Preg_match izpildes laiks: '.($time_end - $time_start).' sekundes.</p>'; ?> </body> </html> Rezultāts: Filter_var izpildes laiks: 0.12879109382629 sekundes. Preg_match izpildes laiks: 0.023126125335693 sekundes. Pie reizes āri pareizības pārbaude. $mail_set = array( "[email protected]", "[email protected]", "[email protected]", "____@___.123", "[email protected] ", ); echo('<pre>'); foreach ($mail_set as $email) echo ($email . " Filter_var - " . (validMail(trim($email)) ? "1" : "0") . " preg_match - " . (validMail2(trim($email)) ? "1" : "0") . "<br>"); echo('</pre>'); Rezultāts: [email protected] Filter_var - 0 preg_match - 0 [email protected] Filter_var - 1 preg_match - 0 [email protected] Filter_var - 0 preg_match - 0 ____@___.123 Filter_var - 0 preg_match - 0 [email protected] Filter_var - 0 preg_match - 0 Domāju ka Filter_var pārbauda vēl kādas papildus lietas, tāpēc arī lēnāk strādā.

Klienta pusē mainīt attēla izmēru nav īsti labi, labāk to izdarīt ar php un pārbaudes ar parastu if kā Kemito teica, neatceros kurš tieši, bet šķiet IE6 sataisa ne visai kvalitatīvu attēlu, pārtaisot attēla izmērus. Otra lieta kāpēc labāk izmēru mainīt servera pusē ir bildes izmērs baitos, ja ļoti liela bilde pie lēnāka interneta ielādēsies samērā lēni, diezgan interesants skats kad šķietami maziņa izmēros bildīte ielādējās pa lēnam.

Sūtīšanas apstiprināšanu var sataisīt kaut kā šādi. <form name="name" action="" method="post" onsubmit="javascript: return confirm('Sūtīt?');"> <div> <input type="text" name="name"> <input type="submit" name="submit_ok" value="OK"> </div> </form> To pašu var likt uz pogas submit notikumu onclick, bet tādā gadījumā datus varēs nosūtīt nospiežot "enter".

Salīdzināšanas nosacījumā izmanto ==.

Es īsti nesaprotu viņu loģiku. Tur īstenībā jebkurš radio ir nopircis atbilstošo mūziku un samaksājis par to, lai varētu to atskaņot publiski. Kāpēc tad AKKA/LAA ir vēlēšanās paņemt naudiņas par lietām kuras jau ir apmaksātas?

Tas, ka darba sludinājumam ir kāds atsevišķi sataisīts pasts vienalga kur ir vēl saprotams, bet kāpēc it kā tik spēcīgai kompānijai vajadzētu baidīties pateikt savu nosaukumu? Prasu tikai ziņkārības pēc.

Par bildītēm piekrītu Aleksejam, ja tās ir nopirktas, tad ir ok, bet ja dizaineris ir vienkārši kaut kur atradis internetā un nokopējis bez atļaujām var sanākt problēmas. Parasti jau vienkārši pieprasa samaksāt par nesankcionētu attēlu izmantošanu un tā pieprasītā summa ir nu ļoti lielāka par pirkšanas cenu. Par pašu lapu, izskatās labi, tikai viena lieta uz ātro apskatot neiepatikās, augšējā daļa ir pārāk liela, ne tikai lielais logo, bet menu arī, tagad ir tā ka pārslēdzoties pa sadaļām lielākā daļa satura ir kaut kur lejā, pie tam tas ir uz normāla monitora, uz platekrāna tas izpaudīsies vairāk. Šai lapai nav aktuāli, bet dažreiz ir vērts padomāt par fona un satura krāsām, tagad ir gaiši burti uz tumša fona, daudz lasot nogurs acis, bet tā kā lasāmvielas ir samērā maz, šoreiz tādu lietu var ignorēt. Tās tādas lietas pie kurām varētu vēl piedomāt, ja ir vēlēšanās, bet visumā lapa ir ok.

Nē, atgriezīs limitētā vaicājuma rindu skaitu, ja tam netiktu izmantots limit, pēc tā rezultāta uzzinām cik ir lappušu.

Total iegūšanai šajā gadījumā varētu izmantot MySql funkciju FOUND_ROWS(), nevajadzēs veidot divus vaicājumus.

FTP ir tikai viena no iespējām. Es jau šeit esmu rakstījis agrāk ka man līdzīga situācija kādreiz radās. Manā gadījumā problēmu radīja nepareizi sakonfigurēts TinyMCE file manageris, kas strādā kā TinyMCE plugins un kā atsevišķs skripts. Es vienkārši viņam nenomainīju noklusētos autentifikācijas uzstādījumus. Ar to arī modificēja failus.

Protams ka būs noderīga. Konkrēti šo neesmu vēl apskatījies, bet jebkura laba grāmata parasti ir noderīga, it īpaši ja sāk apgūt atbilstošo tematu. Dokumentācija ir viena lieta, bet pavisam cita ir grāmata, tur daudz plašāki un saprotamāki piemēri un parasti tiek aprakstītas dažādas nianses. Dokumentācija ir viens, bet pavisam kaut kas cits kad izlasi nopietnas grāmatas, kurās ir arī labi padomi no autoriem.

Marrtins, es nedomāju ka Tu spēsi sataisīt vizītkartes tipa lapu laikā, kamēr sildās ūdens kafijai, ja paskaitīsi pilnīgi visu laiku ko Tu patērē pie projekta ne tikai pie pašas kodēšanas, ja arī spēsi, tad tas nozīmē ka Tev ir pietiekami augsts līmenis sasniegts šajā jomā un ja Tu to esi gatavs atdot par velti, tad tā jau ir Tava personīgā darīšana, bet diez vai to vajadzētu ieteikt citiem.