Citat:
S A J A:
Šta bi konkretno dobio time što bih imao dva identifikatora, jedan public jedan private?
Pogrešno si to razumeo. Nije jedan privatni a jedan javni. Nego je jedan primarni ključ (PK) a jedan je prirodni ključ.
Tehnički gledano definišu se isto: radi se o vrednosti koja mora biti jedinstvena na nivou tabele.
Razlika je u tome što primarni ključ nema i ne sme da ima ama baš nikakvo značenje osim da služi da se identifikuje slog u tabeli i njega određuje sama baza u trenutku kreiranja sloga.
Onog trenutka kada ti zatreba da primarni ključ upotrebiš tako da ima neko značenje to znači da ne treba njega da koristiš nego da uvedeš prirodni ključ. Prirodni ključ je nešto što određuje korisnik baze, bilo tako što ga sam ukucava u bazu ili tako što određuje pravila za nekakvo automatsko generisanje. To se može razlikovati od korisnika do korisnika. Prirodni ključ ima i prednost da njega ne koristiš za povezivanje sa drugim tabelema pa to znači da možeš u bilo kom trenutku da ga promeniš na slogu sve dok je i dalje jedinstven na nivou tabele.
Dobar primer su baš primeri koje si pomenuo: šifarnici komitenata, artikala, radnika i slično. Šifra komitenta, šifra artikla, šifra radnika, to su ključevi koji za korisnika baze mogu i obično i imaju značenje i on ih određuje te su to prirodni ključevi i to ne treba da budu ujedno i primarni ključevi.
Sasvim je realna situacija da korisnik baze u nekom trenutku odluči da promeni način šifrovanja u tabelama u želi da promeni šifre komitenata, šifre artikala, čifre radnika (s obzirom da su to vrednosti koje imaju zančenje on prosto zaključi da mu treba da preorganizuje šifre jer je zaključio da mu postojeća organizacija ne odgovara). To je prilično čest zahtev. Ako su te šifre ujedno i primarni ključevi u nebranom si grožđu jer su ti po njima povezani podaci u raznim drugim povezanim tabelama i menjanje šifre u osnovnom šifarniku znači da to mora da se menja svugde gde se ta šifra koristi. Verovatno to ne bi poželeo ni najcrnjem neprijatelju.
Drugi čest slučaj je da treba da se napravi novi slog za neki entitet ali još uvek nije određena značenjska šifra za entitet. Na primer, na web sajtu se prijavi novu kupac, web sajt prikupi njegove podatke i kreira ga u svom šifarniku kupaca. Onda pošalje te podatke u centralu gde u centralnom šifarniku takođe treba da se kreira taj novi kupac. Tek u centralnom šifarniku se dodeljuje šifra tom novom kupcu. Ako koristiš prirodni ključ kao primarni (šifru kupca), imaš problem jer da bi napravio slog mora da mu se odmah dodeli primarni ključ a ti ga nemaš. Ako je PK beznačenjski možeš odmah da ga dodeliš slogu (autoinkrement na primer) a prirodni ključ može da se dodeli i naknadno.
Slično je, recimo, sa artiklima - zamisli da od dobavljača stigne pun kamion raznorazne robe. Podatke o artiklima imaš ali su šifre artikala šifre koje je odredio dobavljaš, i po pravilu te šifre ti ne možeš da korsitiš nego dodeljuješ svoje. Neke artikle si možda već dobijao ranije pa ih imaš šifrirane ali neke ne. Nema se vremena da se u momentu prijema robe radi i šifriranje (a pošto robu primaju magacioneri oni i ne znaju kako da rade šifriranje) nego se roba prima i umese u bazu sa podacima koji postoje (koristeći beznačenjski primarni ključ za identifikaciju sloga) a tek se naknadno radi šifriranje te robe to jest dodeljuju joj se sopstvene šifre i to se upisuje kao prirodni ključ.
Treći slučaj je autoamtsko generisanje brojeva dokumenata, faktura, opremnica, ranih naloga, ulaza i izlaza magacina i čega sve ne. Brojevi dokumenata se po pravilu određuju po nekoj logici, i to nisu samo proste jednoznačne oznake. Neka vrsta dokumenta može da se kreira na više fizičkih mesta i pri tom, ne mora d azbači da sv amesta imaju uvek pristup centrlanoj bazi nego svako radi sa nekom svojom lokalnom bazom a povremeno radi sinhronizaciju. I sad, kako jedno mesto da dodeli broj dokumenta ako je taj dokument primarni ključ? Nije neizvodivo ali je komplikovano. Ako imaš pored PK i prirodni ključ, koji ćeš PK dodeliti je nebitno,jer je on interni, ali zato prirodni ključ možeš da dodeliš po nekom pravilu, recimo da uvedeš prefiks u broju dokumentakoji određuje loakciju na kojoj je dokument napravljen i tako obezbediš da broj dokumenta bude jedinsten na nivou centralne baze jer svaka će lokacija da koristi svoj jedinstveni prefiks.
U bazi gde su primarni i priodni ključevi odvojeni korisnik baze i ne mora uopšte da vidi i zna za primarne ključeve. On radi sa prirodnjim ključevima koji su njemu bitni i imaju neko značenje. Primarni ključevi su mu obično nepraktični jer su predugi. Zamsili nekoga ko radi sa redom veličine 1000 komitenata a mora da brata sa šiframa dugim 12, 16, 32 ili 64 znaka, zavisi koliko izabereš za primarni ključ. U praksi su mu dovoljna četri znaka. Ili zamisli tek nekoga ko iam hilajde artikala u ifarniku artikaal koji umesto da tim artiklim da neke smislene šifre koje je lako praktično koristiti na kasama, i još koje mogu da imaju neku značenjsku strukturu radi lakše pretrage artikala na kasama, oni moraju da koriste opet neke šifre od 12, 16, 32 ili 64 znaka koje su samo gomila brojeva i slova bez ikakve logike. A njemu je itekako bitna logika u šiframa.
Sve u svemu, kada razdvojiš primarni od pirodnog ključa, trsiš se mnogih problema koji bi te, inače, sačekali i po pravilu te skupo koštali jer ih ne bi predvideo na vreme.
Što se tiče samog primarnog ključa, obuično nema potrebe da uopšte nešto izmišjaš nego korsitiš autoinkrement ceo broj i to je to. Korišćenje karakterinog polja za priamrniključ obično iam smisle tak ako imaš potrebu da ipak daš neko značenje sadržaju priamrnog ključa, ali ne ono koje mu daje korisnik baze nego nešto što ima logoku za tovju apliakciju. Na primer možeš u primarnom ključu kao prefiks da koristiš poslovnu godinu i tako omogućiš fizičko segmentiranje tabele po tom prefiksu, što može znatno da ubrza pristup podacima.
[Ovu poruku je menjao Predrag Supurovic dana 19.04.2021. u 02:50 GMT+1]