Jump to content
php.lv forumi

litt

Reģistrētie lietotāji
  • Posts

    124
  • Joined

  • Last visited

Posts posted by litt

  1. 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?

  2. 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

  3. 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"

  4. 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.

  5. 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

  6. .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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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)

×
×
  • Create New...