|
Korisnici, zadaci i multiple assignees
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 :) |
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! :) |
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) |
Citat:
|
Glasam za LEFT OUTER JOIN koji je sasas pomenuo, umesto budževina. Trigeri? O gospode...
Pozdrav novom korisniku! ;) |
Još jedan glas za rešenje sa LEFT OUTER JOIN - školski primer mesta za njegovu upotrebu ;)
|
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. |
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. |
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. |
Eto, tacno to, pravi skolski primer, prvi na koji naidjes kada citas knjigu :) Hajde kazi mi koliko puta se desilo to o cemu pricas? Da si upisao record pa onda pri pokusaju da upises u tabelu relacije pukne server u istoj milisekundi, tako da je prvi query izvrsio ali drugi nije?
To je kao da ojacavas krov na autmobilu celicnim plocama jer moze neko da ti padne sa zgrade na auto. :) A to sto ce auto da ti trosi vise, ide sporije... mala je cena za 'being safe in case of disaster"? :) Znam da je ovo sto pricam sada jeres za neke, ali ovo govorim kao wake up, jedno je teorija a u praksi to se jednostavno ne desava. Ja sam spreman zbog brzine da "rizikujem" (tih par milipromila verovatnoce), pre nego da razmisljam "sta ako tornado protutnji kroz Beograd" ili "sta ako se na slaviji jednog dana podigne vulkan". Osim toga, u svim ozbiljnijim aplikacijama se prave alati kojima se proverava konzistentnost upisa, cleanup, prune... to moze lako da se sredi ako se i desi jednom u 10 godina. @ilija: 1000 recorda u tabeli je smesno, ako ne ocekujes bar 200k, onda nemoj ni da razmisljas o nekim optimizacijama. :) Da se ja pitam, ja bih to ovako uradio: - stavis u tasks polje "user_id" DEFAULT 0, i u tom polju cuvas kom useru je dodeljen task - u 95% slucajeva, jedan task je dodeljen jednom useru, ako dodelis nekome task - stavis njegov user_id u tabelu tasks - ako ima potrebe da dodelis jos nekome task - dodas ga u assignemnts - kada radis query trazis: where tasks.user_id = 0 OR tasks.user_id = {$moj_id} OR assignments.user_id = {$moj_id} Tu se jedino proceduralno pitanje postavlja sta ako brises nosioca task-a, ongo user_id iz tasks tabele, a ako ima jos nekoga u asisgnements, moras njegov id da prebacis u tasks, a da mu obrises assignement. Ali dobro, radite "by the book", samo mi fali da me neko spali kao jeretika :) |
| Vreme je GMT +2. Trenutno vreme je 11:48. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.