Teorie penibila

Daca solutia ofertita este pentru teme de casa, atunci solutia este ok.
Daca solutia oferita este cod spre productie atunci solutia propusa nu este ok.
Mai exact prezenta lui CROSS JOIN din

FROM dates
								 CROSS JOIN (SELECT DISTINCT articol FROM articole) a
		 ),

si prezenta lui SELECT * din

[SELECT *
				 FROM (SELECT data, articol, cantitate,

Exemplu: la noi in corporatie, am pus filtre ca sa nu-i las pe juniori sa ruleze CROSS JOIN si SELECT * , fortandu-i sa scrie SQL calumea optimizat in mod profesionist.
De asemeni pe echipele de juniori care scriu SQL-ul pt BigData, ii fortam sa optimizeze tot SQL-ul si acolo sa incerce sa formuleze intai cod SQL fara JOINURI daca se poate,
ci sa le folosesca doar daca sectiunea de cod respectiva chiar nu se poate rezolva altfel.
Chiar si atunci cand folosesc JOINURI automat, juniorii nu trebuie sa foloseseasca SELECT * ci sa scrie coloanele respective de manuta.
De asemenea trebuie sa fie atenti cum clusterizeaza fiecare JOIN  si cum isi partitioneaza datele inainte de a intra in JOIN-ul respectv.

De aemenea acest criterii de mai sus, sunt criteriile minimaliste atunci cand trebuie sa scrii cod SQL care ruleaza pe o infrastructura moderna gen  GCP. Acolo orice query SQL neoptimizat genereaza
shufflle suplimentar  de date care costa la buzunar. Adica din cauza unor joinuri  se poate ca 70% din cod sa  doar plimbe datele pe disc prin ram si prin CPU , fara a procesa efectiv informatia utila.
Ori , procesarea pe RAM, CPU si pe disc costa foarte mult bani de acea programatorii sunt obligatii sa scrie cod SQL profesionist si optimizat inainte de a-si rula queriurile  SQL in mediul Big Query din GCP.

CROSS JOIN-uri si SELECT * , in functie de dimensiunea datelor si datorita shuflle-ului de date pe care il implica, pot genera mii de euro cheltuiala degeaba per query in mediul GCP.
De aceea noi am pus filtre pe astfel de chestii si nu numai, iar pentru cei care vin la interviu pt senior Big Data Developer sau  senior GCP developer le dam un test in care bagam soparlele astea sa vedem  daca se prind.

Edited by MartinAdelberg, 27 December 2019 - 10:07.

primele reguli de optimizare ar fi:

• 1.intotdeauna daca ai operatii pe o singura tabela, nu folosi SELF-JOIN ci rescrie algortimul folosind functii analtice, doare nu creaza suffjle suplimentar de date.
  
• 2.daca ai de facut o filtrare a tabela A in functie de tabela B, nu folosi LEFT JOIN ci foloseste un LEFT-SEMI JOIN sau RIGHT SEMI-JOIN doarece nu creaza shuffle suplimentar de date
  
• 3.daca se poate rescrie tot codul SQL fara joinuri, reducand enorm shuffle de date.
  
• 4.daca totusi trebuie facute joinuri partitineaza si clusterizeaza cele doua seturi de date inainte de a intra in join, dupa coloanele de join,pt a mentine la minim sufflle-ul de date suplimentar ce poate fi generat de joinuri.
  
• 5.niciodata nu folosi cross-join-uri si select *.

cu cat ai mai putin shufflle cu atat plimbi mai putin datele prin cpu, ram si disc si scazi timpii morti de procesare, crescand randamentul query-ului  in functie de resursele utilizate si platesti bani mai putin pt timpul de procesare.


Deja companiile cauta programatori care pot scrie SQL optimizat, astfel incat in loc sa te coste 3000 de euro rularea unui query in GCP,  sa te coste 500 de euro, doar prin aplicarea celor 5 principii de mai sus (acolo unde se poate bineinteles)

Edited by MartinAdelberg, 27 December 2019 - 10:22.

Postul la care se refera MartinAdelberg: https://forum.softpe.../#entry25628167

Edited by dani.user, 27 December 2019 - 12:34.

MartinAdelberg, on 27 decembrie 2019 - 10:00, said:

MartinAdelberg, on 27 decembrie 2019 - 10:17, said:

Ne vedem la anu'.

Da' te-ai gandit ca sclavii de pe plantatie sunt dezinteresati. Cu siguranta stiu dar nu vor. Ofera-le un bonus sa vezi ca o sa scrie cum trebuie, adica cei care scrieti cum vreau eu primiti in plus la salar.

MartinAdelberg, on 27 decembrie 2019 - 10:00, said:

s-a gandit vreunul din voi ca "juniori" si "optimizat" sunt niste chestii un pic paralele?
am mai vazut firme d'astea, unde sareau imediat cu "esti inca junior" cand era vorba de salarii, dar uitau de asta cand era vorba de ce li se cerea respectivilor.

junior si optimizat merg mana in mana, indiferent de salar. Un junior cu cap care o sa devina un senior briliant ceva mai incolo o sa invete si o sa optimizeze pt el. Cand o sa vina vremea o sa plece pe x5 salariu de cacao pe care il are la firma x unde a stat cat sa-si faca mana.

daca reusesti sa pleci la o alta firma pe "x5 salariu", asta inseamna un singur lucru: firma anterioara te muncea ca pe un sclav.

Daca initiatorul ar mai si citi cate ceva in loc sa scrie romane de teorie cand vrea sa ofere o critica, ar fi observat ca:

• Beneficiaul interogarii respective a confirmat ca functioneaza rapid si ok.
  
• Platforma in cauza nu era GCP
  
• SELECT * nu era folosit pe un tabel, ci pe o subinterograre specifica

_Smiley_, on 29 decembrie 2019 - 12:27, said:

cand esti muncit ca un sclav inveti o gramada de chestii, ceea ce iti va permite mai incolo sa pleci pe x5 salariu. Una n-o exclude pe alta.

adevarul e ca cei platiti normal nu ajung niciodata sa plece pe "x5 salariu", pentru ca salariul lor creste constant
tu ce ai prefera, sa lucrezi 5 ani pe X salariu si apoi sa treci la X5 salariu, sau sa ai in primul an X salariu, in al doilea X2 salariu si tot asa, pana in al cincilea an cand o sa ai tot X5 salariu? rezultatul final e acelasi (X5 salariu), dar unul a incasat in perioada asta doar 5*X salarii pe cand celalalt a primit 15*X salarii.

nemaivorbind ca cei care-s munciti ca sclavi pe bani putini rareori ajung sa vada acel "x5 salariu", sau chiar daca-l primesc vor descoperi ca e tot sub media industriei. vezi tu, daca ar fi in stare sa obtina un salariu decent, l-ar fi obtinut si la inceput.

Tu pleci de la premisa ca toata lumea ajunge la fiecare sfarsit de an la acelasi nivel din punct de vedere profesional. Teoretic vorbind 2 developeri care au acelasi nivel de skill nu vor progresa uniform daca unul munceste ca nebunul, iar celalalt relaxat. Ala care munceste ca un sclav va avansa mai repede. Dupa 2 ani va avea un salt salarial mai mare decat cineva care creste constant de la an la an, iar dupa 5 diferenta se va accentua. (5 ani nu e interval realist de muncit ca sclav pt ca dai in burn-out, insa).
Si mai e o chestie, unul obisnuit sa munceasca ca un sclav pana la urma isi va da seama care e piata si va pleca sa munceasca ca un sclav pe un salariu mult mai mare decat media pietei, chiar si decat cel care evolueaza constant de la an la an.

ce refuzi tu sa intelegi e ca o astfel de crestere a salariului (de 5 ori) este aberanta, daca discutam de pastrarea domeniului de lucru si a locatiei geografice (relative). si asta nu doar in IT, ci cam in orice domeniu.