Pogledajte određenu poruku
Staro 25. 08. 2007.   #12
Petar Marić
Python Ambassador
Master
 
Avatar Petar Marić
 
Datum učlanjenja: 06.06.2005
Lokacija: Novi Sad
Poruke: 602
Hvala: 28
27 "Hvala" u 17 poruka
Petar Marić će postati "faca" uskoro
Pošaljite ICQ poruku za Petar Marić
Exclamation

Citat:
Originalno napisao bluesman Pogledajte poruku
Sto volite da komplikujete stvari, strasno... samo da bude knjiski - bez obzira sto se radi 3 subselect-a i sto ce taj query da se vuce za sve sto ima preko 100 recorda.
Heh, izgleda da se nismo razumeli - rešenje koje mi se najviše sviđa je:
Kôd:
SELECT * FROM Tasks
LEFT JOIN ass ON
  Tasks.Id = ass.id_task
WHERE
  ass.id_user = {{USER_ID}} OR
  ass.id_user IS NULL
I u njemu ne vidim podupite. Ovakvo rešenje je verovatno dovoljno dobro za najveći broj situacija, inače ne bi bilo preporučeno i ne bi ušlo u knjige.

Citat:
Originalno napisao bluesman Pogledajte poruku
Ali mi razmisljamo drugacije, vi razmisljate "by the book" (zato sam i rekao ono gore) a ja razmisljam odmah o sajtu gde ima 50 000 clanova i u svakom trenutku bar 500 online. Ovde je situacija negde blize vasem slucaju, ali se najezim kada vidim da pored jednostavnog resenja neko preferira subselect-ove
Prvo, čini mi se da je primer promašen pošto (koliko znam) Ilija pravi aplikaciju za upravljanje projektima, a ne forum. Što bi jedan moj prijatelj rekao babe/žabe sindrom

Drugo, verujem da si čuo za izreku "premature optimization is the root of all evil". Daleko od toga da ne treba misliti o njoj u fazama projektovanja i implementacije, ali da razmišljamo samo o sirovoj brzini dan-danas bismo programirali u asembleru (u najboljem slučaju).

Treće, ne vidim kako ti je jednostavnije da sam brineš o integritetu podataka pored mehanizama koje ti sam sistem pruža.

Citat:
Originalno napisao bluesman Pogledajte poruku
Pored toga, mysql po defaultu konvertuje OUTER joinove u dva JOIN-a, tako da to sto vama izgleda "semanticki lepo" i mozes za rever da okacis u stvari je pravi mali genocid za mysql server.
Hm, za ovo ne znam i nisam našao na netu - ali ako je tvoja tvrdnja tačna malo mi je čudno da se upravo MySQL preporučuje za OLAP sisteme koji rukuju ogromnom količinom podataka koristeći join-ove sa nemalim brojem uslova za spajanje.


U zaključku - uvek sam za jednostavna rešenja koja provereno rade a od mene zahtevaju minimalna ulaganja. Tek ako nastane problem analiziram ga, biram osobine za poređenje, optimizujem (refaktorišem ili menjam rešenje), merim osobine, poredim dobijene rezultate, i na kraju donosim odluku.

Nemogućnost merenja osobina, a samim tim poređenja rezultata svodi optimizaciju na čistu masturbaciju - radiš nešto čija je korist u najmanju ruku (excuse the pun) diskutabilna.
__________________
Python Ambassador of Serbia
Petar Marić je offline   Odgovorite uz citat