Zidar Canada
Član broj: 15387 Poruke: 3085 *.100.46-69.q9.net.
|
CREATE TABLE test ( ID identity PRIMARY KEY, Fname varchar(50), Lname varchar(50))
Mogu da unesem isti rekord jedno 10 puta i sistem to ne primeti, jer je zaboga sve u redu, svaki rekord lepo dobije svoj PK, koji je naravno identity i naravno ne znamo sta je dok ne procitamo SCOPE_IDENTITY():
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
INSERT INTO ('pera','Laza')
Nema nista lose u koriscenju identity za PK, osim sto je protiv normalizacije i lako se zapadne u velike nevolje. Pogotovo za pocetnike je opasno, a nazalost je resenja vrlo privlacno. Uvedes identity PK i sve postane savrseno normalizovano naoko. Po definiciji, PK je jedan ili vise atributa koji jedinstveno odredjuje/odredjuju entitet. Pazi, entitet, a ne rekord u tabeli. Entitet postoji nezavisno od tabele i baze, postoji u realnom zivotu. Prema tome, PK za bilo koji entitet mora biti pozant PRE unosa u tabelu. Vrednost za identity NIJE poznata dok se INSERT ne izvrsi. Sledi da identity po definiciji ne moze biti PK. Identiti jedinstveno odredjuje rekord, a ne entitet. A u relacionim bazama ne radimo sa rekordima nego sa redovima (rows) koji odgovaraju entitetima
Necu dalje da raspravljem, to smo vec nekoliko put radili na bazama podataka i svako je ostao na svome. Ko voli nek izvoli i nek se nada da ce front end uhvatiti duplikate pre nego sto udju u bazu, jer identity to ne moze da uradi.
|