Master-child relacije su upravo dobar primer za vestacki PK. Za invoice i invoice item, je ok, mozda i ne moras da uvodis novo polje, ako SIGURNO znas da se to nikada vise nece menjati (stavka 1 ce uvek biti stavka 1 i verovatno je niko nece menjati da bude stavka 3). Medjutim, sta ako je tvoja child tabela istovremeno master tabela nekoj trecoj tabeli, a ta treca tabela master cetvrtoj. To nije retkost u iole slozenijoj bazi. Da li ces tvoja dva foreign key-a da prenosis iz tabele u tabelu? Da li ce peta tabela da ima cudo od 20 kolona za primarni kljuc?
Sto se tice, normalizacije, vestacki kljucevi direktno kvare 3NF koja kaze da svaka kolona koja nije deo PK ne sme da zavisi od druge kolone koja nije deo PK. Kod nas PK je vestacki kljuc, a atributi zavise i od AK (alternativnog kljuca). Pokvarena 3NF? Big deal. Sve sto radis i ucis ima za cilj da tvoj softver bude dobar eksterno (da korisnik bude srecan kada ga koristi) i interno (da ti budes srecan kada ga odrzavas i poboljsavas). Normalizacije moras da znas i da primenjujes, ali ne smes da se plasis izuzetaka kada to ima smisla.
Zombie, "best practices" postoje bas zato da bi se ljudima pomoglo da adekvatno rese probleme koji se javljaju u praksi. Toga cesto nema u fakultetskim knjigama. Tada moras da vuces za rukav nekoga sa vise iskustva, da trazis po internetu, da citas neke druge knjige...
Hm...a sta bese tema ovog topica? :)
A computer once beat me at chess, but it was no match for me at kick boxing.