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