Korisnici, zadaci i multiple assignees

[bluesman]

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

[sasas]

Originalno napisao bluesman

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

[bluesman]

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

[Petar Marić]

Originalno napisao bluesman

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.

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

Originalno napisao bluesman

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
Čisto da znam - jel ta pojava još postoji u 5.x verziji ili samo u 4.x?