Surogatni kljucevi ti trebaju kada:
1. Tabela nema dobrog kandidata za PK.
2. PK je kompozitni sa veliki broj kolona i je kompliciran za upotrebu.
3. Kandidat za PK se koristi u FK relacije i svaka promena bi zahtevala cascade update
Primer koji apsolutno zadovoljava potrebe za surogatnim kljucem,
Tabele:
Code:
MASTER
------------
naziv char(50)
tip int
datum datetime
--------------
PRIMARY KEY (naziv,tip,datum)
DETAIL
------------
naziv char(50)
tip int
datum datetime
ex_data char(100)
--------------
PRIMARY KEY (naziv,tip,datum,ex_data)
FOREIGN KEY fk1 ON naziv,tip,datum REFERENCES MASTER(naziv,tip,datum)
Ako se koriste surogatni klucevi onda bi tabele izgledale ovako:
Tabele:
Code:
MASTER
------------
MASTER_ID int (sequence, autoinc, whatever ...)
naziv char(50)
tip int
datum datetime
--------------
PRIMARY KEY (MASTER_ID)
DETAIL
------------
DETAIL_ID int (sequence, autoinc, whatever ...)
MASTER_ID int
naziv char(50)
tip int
datum datetime
ex_data char(100)
--------------
PRIMARY KEY (DETAIL_ID)
FOREIGN KEY fk1 ON MASTER_ID REFERENCES MASTER(MASTER_ID)
I polja koja su bili PK u prvom slucaju sada mogu imati samo UNIQUE constraint.
People who think they know everything tend to irritate those of us who do.