Citat:
Zidar:
Sto se tice ID autonumber ili ne, sve dok je Skola unique, to moze da prodje. Medjutim, treba biti veoma oprezan sa upotrebom Autonumber. Vrlo lako moze da se desi da pobrkas absolunto sve podatke a da nisi ni svestan. Upotrebu autonumber za "povezivanje tabela" mogu sebi da priuste samo stare kuke, 50+, kao Zonic ili Predrag S. jer znaju sta rade. Za sve ostale - kloniti se Autonumber, jer cete dobiti laznu sliku o integritetuu podataka.
Rekao sam najpraktičnije je, nisam rekao da je obavezno koristit Integer autoincrement.
Ne znam na šta misliš da se sa autoincrement mogu da se pobrkaju podaci. Jedina nezgoadija je što su sve veze neznačenji brojevi pa kad otvoriš tabelu direktno u bazi ti brojevi ti ne znače mnogo već uvek moraš nekako da ih povezuješ sa drugim poacima da bi ih prepoznavao.
Kad se prirodni ključ koristi kao PK onda je obično i prepoznatljivo njegovo značenje i to je obično osnovni razlog zašto neko koristi Prirodni ključ za PK.
Međutim, korišćenje prirodnog ključa kao PK je vrlo često prizivanje problema. Čim je prirodni ključ to znači da ima neko značenje, a ako ima značenje postoji uvek verovatnoća da se vresno promeni, da se značenje promeni, ili, da se pojavi neka druga komplikacija sa njegovim tumačenjem. Kada koristiš veštački ključ kao PK taj problem je isključen, jer veštački ključ nema značenje, jedina mu je svrha da jednoznačno identifikuje slog tabele.
Primer prvi: recimo da neko pravi tabelu osoba i uzme broj lične karte, što je prirodni kluč, kao primarni ključ. Greška je mnogima (ali ne svima) očigledna, jer se broj lične karte menja, pa kad neko promeni ličnu kartu, treba u tabeli da mu se to promeni a promena vrednosti koaj je primarni ključ nije baš naivna niti poželjna.
Slično je i sa navedenim primerom korišćenja registarske tablice kao identifikatora vozila zato što su tablice promenljive.
Primer drugi: programer koji malo razmisli će da zaključi da broj lične karte ne može da koristi kao primarni ključ pa će umesto toga da iskorsiti drugi prirodni ključ: matični broj. Mnogi će se zakleti da je matični broj jedinstven i nepromenljiv jer to tako treba da bude ali će kad-tad saznati da to u praksi nije tako i eto problema istih kao i sa brojem lične karte.
Kod vozila, neko će umesto registarskog brojq da uzme recimo broj šasije kao prirodni i primarni ključ. Broj šasije je zaista teško promenjiv ali nije nepromenljiv, dakle, može da se desi da se i on promeni, pa ni to nije dobar identifikator vozila.
E zato treba uvesti veštački ključ kao primarni ključ i otkačiti se zavisnosti od pravila vezanih za brojeve ličnih karata i matičnih brojeva, registarkih tablica, brojrva šasija i slično.
Primer treći: jedan od entiteta u ovoj bazi o kojo pričamo su stolovi i rečeno je da svaki sto ima id broj koji mu dodeljuje proizvođač i koji je jedinstven i stoga je on kao prirodni ključ uzet za primarni.
Međutim, šta ako se desi da dva proizvođača nekako pogode pa uvedu isti id broj za svoje stolove (koji su naravn različiti proizvodi) i naprave preklapanje? Šta ako se pojavi neki novi proizvođač koji dodeljuje iste id brojeve kao neki drugi proizvođač? Mi svakako ne možemo proizvođačima da namećemo kakve će oni id brojeve da dodeljuju svojim proizvodima. Možemo samo da preuzmemo id brojeve onakve kakvi su.
Stoga, otkačimo se od id broja kao primarnog ključa, uvedemo svoj inteni ključ koji će imati ulogu PK i postajemo potpuno nezavisni od toga kakav id broj ko dodeljuje svom proizvodu. Id broj čuvamo u bazi jer, ako po pitanju nekog stola (recimo radi reklamacije), kontaktiramo proizvođača on će nam tražiti i taj svoj id broj da bi znao o kom se stolu radi jer taj id broj njemu nešto znači.
Sve se to svodi na isto: dobro je steći naviku da se za primarne ključeve ne koriste prirodni ključevi.
Citat:
Svrha PK i FK NIJE da se "povezu tabele". Svrha je da se zahteva da vrednost u nkom polju date tabele (dete) mora postojati u nekoj drugoj tabeli (Roditelj tabela).
Povezivanje je opštiiji pojam i obuhvata sve vrste povezivanja i ne znači obavezno i da slog sa određenom vrednoti mora postojati u roditeljskoj tabeli (mada se najčešće očekuje i zahteva da postoji). U praksi to u stvari može da bude i prilično složeno pitanje. Da nije tako, onda ne bi pstojali LEFT I RIGHT JOIN nego samo INNER JOIN.