DevProTalk - Korisnici, zadaci i multiple assignees

DevProTalk (http://www.devprotalk.com/index.php)

- SQL baze podataka - Sponzor: Baze-Podataka.net (http://www.devprotalk.com/forumdisplay.php?f=10)

- - Korisnici, zadaci i multiple assignees (http://www.devprotalk.com/showthread.php?t=3426)

Citat:

Originalno napisao bluesman (Napišite 41045)

Eto, tacno to, pravi skolski primer, prvi na koji naidjes kada citas knjigu :)

Jok, ja sam knjiga (a marfi je čudo) ;) Sve je stvar nekakvog trejd-ofa, kao što rekoh treba meriti - ja bih na primer uvek išao i na taj delić promila da se (ma koliko nepotrebno) zaštitim radije nego da dobijem koji promil u brzini. Ali definitivno bi presudilo to da je left join == manje programiranja za isti rezultat, ne možeš poreći da nam teorija ovaj put skraćuje posao :)

pozz

Citat:

Originalno napisao bluesman (Napišite 41035)

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 (Napišite 41035)

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 (Napišite 41035)

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

Ja sam komentarisao predlog:

SELECT * FROM Tasks WHERE Id IN (SELECT id_task FROM ass WHERE id_user = 1) OR Id NOT IN (SELECT id_task FROM ass)

Nadam se da vidis subquerije ovde gore ^. Po meni - jako lose resenje.

Da se ne nastavljamo, potrazi na netu, a mozes i u mysql manualy, odeljak optimization, kako se outer joinovi konvertuju u seriju inner joinova. Ja ne kazem da se ne koristi outer join, vec da se koristi kada ima potrebe za to. Ali opet, sta ja znam o tome? ... radi kako hoces :)

Citat:

Originalno napisao bluesman (Napišite 41054)

Slažem se da je to lošije rešenje, ipak je bila greška u komunikaciji - izgleda da si mislio da podržavamo podupite umesto left join-ova - as if :1031:

Citat:

Originalno napisao bluesman (Napišite 41054)

Da se ne nastavljamo, potrazi na netu, a mozes i u mysql manualy, odeljak optimization, kako se outer joinovi konvertuju u seriju inner joinova. Ja ne kazem da se ne koristi outer join, vec da se koristi kada ima potrebe za to. Ali opet, sta ja znam o tome? ... radi kako hoces :)

Obavezno ću pogledati sutra, kad budem odmorniji :1014:
Čisto da znam - jel ta pojava još postoji u 5.x verziji ili samo u 4.x?