Jump to content
php.lv forumi

litt

Reģistrētie lietotāji
  • Posts

    124
  • Joined

  • Last visited

Everything posted by litt

  1. SELECT COUNT(1) FROM tabula WHERE kolonna = vērtība;
  2. if(nosacījums){ darbība; }else{ cita darbība; } Pie else nekas na jāraksta, ja vien tas nav esle if
  3. Pamēģini ielikt jaunā failā un paskaties kas notiek. Pamēģini ielikt index.php un paskaties kas notiek. Kurš Tavā vietā mēģinās, ja ne Tu pats?
  4. litt

    Algas

    Vairumā gadījumu darbinieks grib, lai viņa alga augtu attiecībā pret nostrādāto laiku gados/mēnešos (kuru daudzi uzskata arī par "pieredzi"). Taču darba devējam ir svarīgi, lai darbinieks ar savu reāli padarīto darbu, nevis "pieredzi" atpelnītu sevi. Labs piemērs no dzīves. Lielā uzturēšanas projektā strādāja cilvēks A (jau gadus 2) un atnāca civēks B. Pēc ~9 mēnešiem reāli izdarīto darbu saraksts noteiktam periodam izskatījās apmēram tā: cilvēkam A 10 padarīti darbi, no kuriem visi ir kategorijā viegls vai vidējs. Cilvēkam B sarakstā ir 17 izdarītie darbi, no kuriem 5 ir kategorijā sarežģīts, 7 ir kategorijā vidējs un pārējie ir viegli. Retorisks jautājums: kuram no darbiniekiem darba devējs palielinās algu? Vai tam, kuram tūlīt būs jau 3 gadu pieredze, vai arī "jaunajam" darbiniekam, kuram darba pieredze vēl nav gads. Vēl pāris retoriski jautājumi: kurš no darbiniekiem ir pelnījis lielāku algu? Ja kādu dienu abi darbinieki izdomātu mainīt darba vietu, par kuru no darbiniekiem darba devējs cīnītos, piedāvājot, lielāku algu/citus labumus? Secinājums ir pavisam vienkāršs: kamēr darbinieks ar savu reāli padarīto darbu sevi atpelna, darba devējs var celt algu un nesatraukties. Ja darbinieks ar savu padarīto darbu nespēj darba devējam atpelnīt tos pašus 400 latus, tad tāda alga arī paliks un diez vai tuvākajā laikā kaut kas mainīsies. P.S Ir ļoti daudz "aptaujas", kur cilvēki vēlas zināt šo un to, bet gandrīz nevienā pats aptaujas autors neatbild uz savu uzdoto jautājumu. Kā tad būs, Robi, pats atbildēsi uz savu jautājumu?
  5. Izmanto 3 tabulas: rakstu tabula, atslēgvārdu tabula un tabula, kurā glabājās katra raksta sasaite ar vienu vai vairākiem atslēgas vārdiem
  6. Ja pareizi saprotu jautājumu, tad select count(1) from (select count(1) c, id from tabula group by id) t where t.c = 1 P.S kverijs uz ātru roku rakstīts, gan jau ir iespējas to nooptimizēt vai pārrakstīt savādāk, bet idejiski kaut kā tā..
  7. Programmēšana nenozīmē zināt 100 funkcijas no galvas.. Programmēšana nozīmē IZDOMĀT KĀ ar pieejamiem līdzekļiem kaut ko var realizēt.. Ja Tu nevarēsi izdomāt, ka taisnstūra laukumu aprēķina mala * mala, tad arī 1000 funkciju zināšana Tev nepalīdzēs
  8. Ja Tev sekundē neveidojās miljons jaunas sesijas, tad var vienkāršāk.. Glabā nevis ID, bet timestamp + kaut kāds randoms. Katru sekundi timestamps mainīsies, random palīdzēs izvairīties no kļūdām, ja senkundes laikā izveidojās vairāk kā 1 sesija. Lauka garums gan būs lielāks, toties tas būs konstants un neizies "no rāmjiem"
  9. Apskaties kas glabājās $_SERVER masīvā. Ja no tur esošajiem elementiem Tu nespēsi sakombinēt to, ko Tev vajag, tad varbūt ir vērts pameklēt citu hobiju.. Programmēšana nav kaut kādu kodu iekalšana no galvas. Programmēšana ir domāšana.
  10. Ja pareizi saprotu Tavu problēmu, tad: ciklā ej cauri failam un explodē pa | ja $masivs[0] == portfolio, tad $masivs[3] explodē pa # ej cauri visiem jaunā masīva elementiem un explodē pa : rezultātā Tev būs vesela čupa ar masīviem, kuros būs visi vajadzīgie elementi P.S Katrā vietā saliec print_r vai echo un skaties kas ir sanācis, lai pašam pēc tam nav jābrīnās
  11. litt

    mod_rewrite

    .htaccess RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?path=$1 [QSA,L] Padotais URLis būs mainīgajā $_GET['path'] Tālāk jau elementāri, ņem explodē pa slash un kombinē kā patīk
  12. Saliec masīvā virknes elementus, sakārto un tad skaties vai viena masīva pēdējais elements nav lielāks par otra masīva pirmo elementu
  13. litt

    Noslodze

    Kaut kādus operatīvos datus (piemēram, online lietotājus) var glabāt arī MySQL memory tabulā, tb datus varēs iegūt ar parasto selektu, bet tas notiks ātrāk, jo dati glabājās atmiņā, nevis failā. Nevaru komentēt par šī varianta efektivitāti, jo ir jāizvērtē vairāki kritēriji: piekonektēties pie bāzes vajadzēs, ja ir daudz dati, tad aizistīs daudz atmiņu.. Plusi tādi, ka ar selektu ir daudz vieglāk atlasīt datus, nekā no faila kaut ko lasīt un pēc tam filtrēt
  14. litt

    Noslodze

    1. Normāla datubāzes struktūra 2. Optimāli salikti indeksi 3. Piefīčoti selekti (nekādi SELECT * FROM, pēc iespējas mazāk tabulu FULL skani) 4. Ja iespējams, tad datus atlasīt 1 reizi un pēc tam ņemt no kešatmiņas 5. Pēc iespējas nedarbināt selektus iekš cikla
  15. Katru nakti (jo tad servera noslodze parasti ir vismazākā) palaist procesu, kurš dzēš ierakstus
  16. litt

    Sūdzība!

    Meklējot darbu, iesaku vērsties pie darba devēja nevis caur kaut kādu forumu ar mistisku nickname, bet normāli aizrakstīt pieteikuma vēstuli, piezvanīt. Pavisam nopietni.
  17. Ar 2 tabulām nepietiek, jo vienai grāmatai var būt vairāki autori un vienam autoram vairākas grāmatas. Tabula 1 - autori, tabula 2 - grāmatas, tabula 3 - linku tabula, kur ir tikai autoru un grāmatu ID kombinācijas
  18. Piebildīšu andrisp, ka vajag nopietni par to padomāt, jo parent_id liekot 0 (vismaz ORACLE gadījumā) nav iespējams veidot ForeignKey ar visām no tā izrietošajām sekām + būs problēmas ar hierarhiskajiem selektiem. Ja parent_id nav, tad NULL
  19. litt

    Dalisana pa 2

    Vai tiešām tik grūti izdomāt veidu kā to noteikt? Elementāra matemātika
  20. Protams, ka zinu.. Bet šajā gadījumā par to negāja runa. Es pieņēmu, ka dzēšot ierakstu ar ID = 3 tika izdzēsti arī saistītie ieraksti un pēc tam "tukšā" vieta aizpildīta ar jaunu ierakstu. Runa gāja par to, ka vienu dienu es pēc SELECT * FROM tabula WHERE id = 3 dabonu vienu (arī atbilstošos saistītos ierakstus, ja paplašinātu kveriju), bet pēc 2 dienām izpildot to pašu kveriju dabūju pavisam citus datus
  21. ID ir UNIKĀLS identifikators un tā tam vajadzētu būt, savādāk sanāks tā, ka vienu dienu pēc ID = 3 atradīsi vienu ierakstu, nākamajā dienā kaut ko citu, jo, redz, kāds būs veco ierakstu ar ID = 3 izdzēsis un tā vietā tavs mega tukšumu aizpildošais algoritms būs ielicis iekšā kaut ko citu. Ja Tev DB ir viena tabula un paša vajadzībām, tad tā var darīt, ja DB ir 100 tabulas un ir atsauce uz konkrēto ID vēl 15 tabulās, tad tāds piegājiens pie pirmās izdevības pilnībā nograus visu sistēmu
  22. Ja WHERE code1 = 'x' atlasa 100 ierakstus, bet WHERE code2 = 'y' atlasa 20 ierakstus, tad indeksā kā pirmo norāda code2 (code2, code1)
  23. Ja pareizi atceros, tad pie saliktajiem indeksiem kā pirmo vajag norādīt to kolonnu, kura visvairāk ierobežo datu atlasi Defaultā Oracle liek indeksu arī tad, ja kolonnai uzleik unique konstreintu
  24. Indeksus noteikti vajadzētu likt uz PK (Primery Key) kolonnas un uz FK (Foreign Key) kolonnām Ar indeksiem noteikti nevajag aizrauties, jo pie lielām tabulām tas pazemina performanci pie insertiem (ja būs indeksi uz visām kolonnām, tad pie inserta visi ir jāpārveido un x miljonu tabulai tas prasīs laiku)
  25. Pats neaizdomājies pamēģināt? Ar kādu 3. reizi gan jau būtu nonācis pie kaut kā līdzīga.. $name = htmlspecialchars(stripslashes($_POST['name']));
×
×
  • Create New...