Korisnici, zadaci i multiple assignees

[Ilija Studen]

Model je prilično jednostavan. Imamo korisnike, zadatke i zaduženja gde na jedan zadatak može da bude stavljeno više korisnika:

users -< assignmnets >- tasks

Gde je assignments klasična vezna tabela:

user_id
task_id

Ono što kvari jednostavnost rešenja je to da ako zadatak nema direktno dodeljene korisnike onda se smatra svačijim i treba da se nađe u listi svih korisnika (Assigned to Anyone).

Ovo lako mogu rešiti, ali rešenja koja mi padaju na pamet nisu baš najsjajnija - ili zahtevaju više upita ili keširanje ili slične gluposti.

Da li je moguće jednim upitom izvući sve zadatke dodeljene korisniku uključujući i one koji nemaju nikog dodeljenog zadacima ili? Svaka ideja je dobrodošla

[sasas]

Ako sam dobro skapirao problem, možda ti nešto od ovoga pomaže:

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

SELECT * FROM Tasks LEFT JOIN ass ON Tasks.Id = ass.id_task
WHERE ass.id_user = 1 OR ass.id_user IS NULL

Pozdrav

ps. eh, ovo mi je prva poruka ovde, pa kako je red i običaj: POZDRAV SVIM FORUMASHIMA!

[bluesman]

A da probaš da za taskove koji nemaju assigned users dodaš sve jedno key (task_id, 0) u tabelu assignments, i kada čitaš čitaš:

SELECT * FROM assignments WHERE user_id = $user_id OR user_id = 0;

i tako dobiješ sve njegove taskove + one koji su dodeljeni svima?

Možda nije rešenje by the book, ali bi moglo da radi. Pri tome bi morao da radiš proveru kada god dodeljuješ assignments, recimo ovako:

- kada se kreira task, ako nije uneo user id - automatski se dodeljuje svima i kreiraš (task_id, 0)
- ako kasnije dodeli nekome assignment, odmah obrišeš (task_id, 0) jer više nije "svačiji"
- ako kasnije opet obriše taj assignment, proveriš da li ima još neko kome je dodeljen isti task, ako nema opet kreiraš (task_id, 0)

[dee]

- ako kasnije dodeli nekome assignment, odmah obrišeš (task_id, 0) jer više nije "svačiji"
- ako kasnije opet obriše taj assignment, proveriš da li ima još neko kome je dodeljen isti task, ako nema opet kreiraš (task_id, 0)

i to triggerom ako ima mysql 5

[jablan]

Glasam za LEFT OUTER JOIN koji je sasas pomenuo, umesto budževina. Trigeri? O gospode...

Pozdrav novom korisniku!

[Petar Marić]

Još jedan glas za rešenje sa LEFT OUTER JOIN - školski primer mesta za njegovu upotrebu

[bluesman]

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

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.

[sasas]

Ne razmišljam(o) "by the book" nego "by the myrphy", pa na primer:

INSERT INTO Tasks (...)
<-- UPS, SOME ERROR... -->
INSERT INTO Assigments (id_task, 0)

ti bazu dovodi u bezveze stanje, ili što bi knjiški moljci rekli "nekonzistentno" Nije naivno, posle se task neće ni kod koga prikazati. Ono jest da postoje transakcije, ali opet nisu ni one šampion brzine...

Imho, treba koristiti sve elemente koje jezik (sql ili neki drugi) pruža, pogotovo što su megaherci svaki dan sve jeftiniji

pozz

ps. svakako bi bilo najbolje meriti rezultate za svaki konkretan primer, bez toga je bez'ze išta pričati.

[Petar Marić]

Originalno napisao bluesman

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:

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.

Originalno napisao bluesman

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.

Originalno napisao bluesman

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.

[Ilija Studen]

Sad sam baš ubacio LEFT OUTER JOIN. Tabela trenutno ima samo 1000 rekorda (query izvlači oko 160) i ne primeti se da je upit nešto spor.

Mogu postovati konstrukciju i EXPLAIN ako ćemo da zalazimo u detalje. Meni je to prilično nova priča pa možda ne bi bilo loše da prodiskutujemo na konkretnom primeru...

Btw - u pitanju je nova verzija activeCollaba, ne skript community kalibra gde ima 500 posetilaca istovremeno.