Mozda je "nikad" prejaka rec, jer uvek postoje izuzeci. Nikad ne reci nikad. :)
Kljucevi od jednog numerickog/autoincrement polja su zgodni ako sa njima ne radite direktno, nego kada kljucevima manipulise softver (sto se cesto desava, na primer u EJB ili ako imate persistence layer izmedju vase aplikacije i baze).
Dalje, ako imate 5 - 10 tabela, mozete da radite sta god hocete. Sta ako imate 300 tabela, gde dobar deo kljuceva ima vise polja. Na primer, kod jednog klijenta, ugovor se definise (kljucem) kao kombinacija od 5 polja (i sva su potrebna), a ugovor se referencira u 50-ak tabela. Ako bismo tih 5 polja uvek stavljali kao deo foreign key-a, bilo bi uzasno (kao sto neko rece, upiti bi bili mnogo duzi, tezi za odrzavanje itd). Sta ako imate foreign key-a sa 2 kljuca i svaki ima vise polja? Kako ce taj query da izgleda onda? Ne daj boze da se vrednost u nekim od ih polja promeni (iz bilo kog nenormalnog razloga kojih uvek ima). Obzirom da svako od tih polja ima smisla u busniess domainu, to je sasvim moguce i regularno. Pera se vise ne zove Pera, nego Djoka. Onda bismo imali...kako ono bese, kaskadni update? Ako imate kljuc koji je samo kljuc i vrednost je besmislena za business domain, onda vrednost tog kljuca NIKADA (opet ta rec) ne moze da se promeni i nema problema sa kaskadnim update-om. Drugo, u praksi se ponekad ne definise foreign key. Ta praksa je losa, ali ljudi to ponekad rade da bi mogli lakse da manipulisu i pisu/brisu podatke, posebno kod raznih konverzija, migracija i integracija. Ako tada imamo promenu u primarnom kljucu, izgubicemo vezu sa tabelama u kojima nismo definisali foreign key...Znam da je lose, ali to se desava, a ne mozete uvek da kukate na neciji los dizajn. Neko ceka na softver (i mase parama).
Dakle, svaka promena vrednosti primarnog kljuca je losa tj. komplikuje zivot jedne baze. Zato su i uveli te vestacke kljuceve koji na prvi pogled nemaju smisla. Taj koncept nije uvek lako razumljiv i intuitivno jasan i zato toga retko ima u knjigama za studente. Bar se secam kako sam se ja nervirao i osporavao te vestacke kljuceve.
Kada se dizajnira baza, nije lose biti dosledan kada se jednom izabere kako ce se modelirati kljucevi. Ako moramo da uvedemo vestacke kljuceve na 3 tabele, bolje je da ih uvedemo svuda. I obrnuto.
Problem sa duplikatima se resava uvodjenjem alternativnih kljuceva (unique constraints), kao sto je rekao Zidar. A izuzetke je uvek dobro ciniti kada to ima smisla.
Uzgred, sto se tice autoriteta, ja se izvinjavam profesorima, ali meni oni to nikada nisu bili, iako sam bio dobar u skoli :) Uvek sam vise voleo da cujem ljude iz prakse.
A computer once beat me at chess, but it was no match for me at kick boxing.