Spoljni kljucevi u MS SQL

CREATE TABLE osnovna
(
Ident int IDENTITY NOT NULL,
Ime varchar(25) NOT NULL,
Konto int NOT NULL,
Stanje int NOT NULL,
CONSTRAINT PrimarniKljucO
PRIMARY KEY (Ident, Stanje)
)

I sada "EXEC sp_helpconstraint osnovna" mi pokaže da u tabeli Osnovna imam ograničenje tipa PRIMARY KEY sa imenom PrimarniKljučO i da su to Ident i Stanje.

CREATE TABLE dete1
(
Ident int IDENTITY NOT NULL,
Saldo int NOT NULL,
CONSTRAINT PrimarniKljucD
PRIMARY KEY (Ident),
CONSTRAINT SpoljniKljuc
FOREIGN KEY (Saldo)
REFERENCES osnovna (Stanje)
ON UPDATE CASCADE
ON DELETE CASCADE
)

Prijavi mi da u tabeli Osnovna nemam ograničenje Stanje!!!!!!!!
Molim za pomoć.

Slucajno sam dosao na tvoj zahtev jer sam skoro postao clan ovog foruma. Ja tvoje pitanje uopste ne razumem. Zasto si gurnuo ident i stanje kao PK. IDENTITY kolona ti je dovoljna za PK. Kako mislis da napravis relaciju izmedju dve tabele gde su ti IDENTITY kolone u PK kljucevime. Nista mi nije jasno sta hoces? Nego ti lepo na Srpskom opisi (kao pricu) sta zelis da postignes, a ja cu ti poslati SQL code za te dve tabele.

Pozdrav,
Milovan

Spoljasnji kljuc u jednoj tabeli mora da bde isto sto i Primarni kljuc u parent tabeli.
U tabeli Osnovan stavo si PK je PRIMARY KEY (Ident, Stanje).
U tabeli Dete1 treba da stoji
FOREIGN KEY (Ident, Saldo)
REFERENCES osnovna (Ident, Stanje)

Medjutim tvoj Dete1,Ident je takodje IDENTITY a ne bi smeo da bude. Sme da bude recimo INT ili BIgINt i da se prepisuje iz tabele Osnovna kad kreiras novi Dete1 record. Ovako kako sis stavio, u tabeli Dete1 polje Ident se inkrementuje automatski, nezavisno je polje i cela stvar ti nece raditi makar i kad bi apisao FOREIGN KEY i REFERENCES korektno.

Samo da spomenem da i ako kreiras Dete1, kako ti je savetovao Zidar, ce (mozda)raditi sa tehnicke strane ali to nema nikakvog smisla u praksi, jer povezivanje atributa saldo sa atributom Stanje gde su ukljucene IDENTITY kolone je izvan svake logike - voleo bih da mi neko da primer gde je to primenljivo. Ko moze da tvrdi da ce to raditi i u kom slucaju?

Kao prvo, kriscenje IDENTITY kolona u dizajniranju baze je los obicaj. SQL Server nije ACCESS. Uvek bi trebalo da se koristi 'SIFRA' proizvoda ili 'Akaunt' ili bilo koji drugi atribut koji je 'unique' i koji ce podrzavati treci level normalizacije. Kao definiciju mozemo da kazemo da je PRIMARY KEY - FOREIGN KEY - 'lookup' relacija, sto znaci da u tabeli 'A' ciji je PK u stvari FOREIGN KEY u tabeli 'B', ne moze da se pojavi novi PK kojeg nema u tabeli B. PRIMARY KEY bi trebalo da bude unique. Glavna osobina PK je da ga prati 'clustered unique index'.
Ja uopste ne stavljam PK na moje tabele kada dizajniram bazu, ali za svaku tabelu kreiram 'unique clustered index' i potrebne 'non-clustered' indexe. Time dobijam vecu fleksibilnost za buduce promene u dizajnu a u isto vreme mogu da postavim PK-FK relaciju.
Neko ko dizajnira bazu mora da pravi razliku izmedju 'constraints' i indexa. Ja radim dugo kao DBA/Database Arhitect i iz mog iskustva mogu reci da gde je god aplikacioni programer dizajnirao bazu tu su problemi pocevsi od performance pa do prljavih podataka (orphan rows itd..). Aplikacioni programer (c,Java, VB, ASP...) misli na nivou rekorda (do..while, for.. next) dok database developer razmislja na nivou data seta (SELECT). To su totalno dve razlicite filozofije. Iz mog iskustva vam mogu reci da sam nailazio na kod gde su aplikacioni programeri stavljali SELECT/DELETE/INSERT/UPDATE/StoredPprocedures kao embedded SQL kod u okviru svojih DO...WHILE programskih struktura. Jos kada nadjes to isto ali sa SQL Dynamic embedded upitima onda ne znas da li da places ili da se smejes, ponked mozes i da zaplaces od smeha.

Pozdrav,
Milovan


Spoljasnji kljuc u jednoj tabeli mora da bde isto sto i Primarni kljuc u parent tabeli.
U tabeli Osnovan stavo si PK je PRIMARY KEY (Ident, Stanje).
U tabeli Dete1 treba da stoji
FOREIGN KEY (Ident, Saldo)
REFERENCES osnovna (Ident, Stanje)

Medjutim tvoj Dete1,Ident je takodje IDENTITY a ne bi smeo da bude. Sme da bude recimo INT ili BIgINt i da se prepisuje iz tabele Osnovna kad kreiras novi Dete1 record. Ovako kako sis stavio, u tabeli Dete1 polje Ident se inkrementuje automatski, nezavisno je polje i cela stvar ti nece raditi makar i kad bi apisao FOREIGN KEY i REFERENCES korektno.

MilovanB je 100% u pravu. Da se ja pitam, njegov post bih odvojio kao TOP temu, da svako vidi i procita. Mozda bi onda bilo manje smesnih i tuznih resenja.

Iz prakse, 90% problema je u dizajnu baze, a samo 10% u programiranju. Medjutim, 90% ljudi pokusava da probleme dizajna baze resi ili nekako prebrodi pojacanim programiranjem, sto samo dovodi do potrebe za novim i novim programiranjem. Jedan od Marfijevih zakona glasi otprilike ovako - glupost u sistemu raste dok ne ugusi ceo sistem.

:-)

Zdravo.

Dodaci i korekcije na gore navedeno.
Nije tacno da kod formiranja relacija spoljasnjeg kljuca, parent polje mora da bude samo Primary Key. Vec moze da bude bilo koje UNIQUE polje, bez obzira da li je u kljucu ili nije.

Dalje, koriscenje IDENTITY polja nije nepozeljno, daleko od toga. Vec se koristi prema situaciji. Ispravno resenje za MilovanB navod jeste sa dodatkom:

Da treba koristiti i IDENTITY field, ali i vezivati se za realni UNIQUE proizvoda. Sa tim sto se clastered index obavezno skida sa primarnog kljuca ako je on istovremeno i IDENTITY, i stavlja se na polje/a koja su realno najopterecenija pretrazivanjem i za to postoje alatke za analizy u SQL serveru.

Tvoje resenje, e5944, je dobro, ali moze biti i mnogo bolje. Najgore bi bilo da uopste nista ne radis. Niko od nas se nije naucen rodio pa da moze odmah da soli pamet ili da ne prasta greske.

Samo napred bice sve bolje i bolje.

Pozdrav

Aplikativni programer kaze da je 10% baza 90% aplikacija, DBA kaze da je obrnuto ... a ustvari najveci deo posla obavi Systema architect. Nije posao aplikativca da razmatra globalni dizajn aplikacije niti je posao DBA da stvori logicki data model. Aplikativac i DBA mogu samo dobro obaviti posao i uraditi stvar kao sto treba ili mogu loso obaviti posao i to je to. Svaka komponenta u jednom sistemu je podjednako bitna.

Ovo sto ti MilovanB i Majstor kazu je osnova DB dizajna i svaki dobar aplikativac ili sys architect dobro poznaje, tako da problemi koji su oni potencirali su problemi neiskusnih DBA/aplikativca. Nemozes biti dobar DBA ako nemas gram Aplikativnog iskustva i obrnuto.

I znaj da aplikacije i baze evoluiraju. Ono sto je danas dobar dizajn sutra ne mora biti.

Potpis

People who think they know everything tend to irritate those of us who do.

Dobro, u redu, ali sta je alternativa kad nema realnog kljuca?

uniqueidentifier polje sa DEFAULT (newid())?

uniqueidentifier, newid()?

Mozda ce da zvuci smesno ali nisam koristio uniqueidentifier jer mi je nekako velik.
Inace, interesuje me, pa nije li onda isto. Koristiti newid() ili IDENTITY. I jedan i drugi
postavljaju novu vrednost prilikom INSERT-a.
Ne razumem svrhu IDENTITY-a ako ispada sad, da ne treba da se koristi.

Odgovoriće verovatno i neki DBA, ja mogu svoje mišljenje da ti dam.

Nije isto koristiti DEFAULT i IDENTITY zato što ti, u opštem slučaju, baza ne dozvoljava da dodaš koju hoćeš vrednost u IDENTITY polje.

Npr. imam aplikaciju koja interno radi sa datasetovima, tipa ima master-detail tabele. U svojoj aplikaciji hoću da dodam novi red u master tabelu i nekoliko stavki koje mu odgovaraju u detail tabelu. Ako radim sa identity, moram da radim prvo upis u master tabelu i da vidim koji ID mi je novi slog dobio, postavim taj ID u foreign key novokreiranih detail slogova i tek onda upišem detail slogove u bazu.

Kad radim sa GUID-ima (UNIQUEIDENTIFIER), generišem slučajan GUID u aplikaciji i koristim ga kao ključ. Pri upisivanju onda nemam problema, tj. mogu u cugu da grunem u bazu i master i detail slogove bez potrebe za nekim dodatnim muljanjem između.

Takođe, IDENTITY polja mogu da prave probleme ako imam više baza sa kojima klijenti nezavisno rade, pa treba u nekom trenutku da merdžujem podatke (javljaju se dupli ključevi, pa moraju da se menjaju, i onda tu logiku treba ispratiti i u ostalim tabelama gde se taj ključ pojavljuje kao spoljni)...

Generalno, postoje slučajevi kad se može koristiti IDENTITY, ali je lakše potpuno ih izbaciti iz upotrebe, na duže staze manje boli glava.

Slazem se!

@jablan
Uglavnom, hvala na odgovoru.

Nego... ovakvih tema bi trebalo da ima vise. Svi koji (ne)planiraju da se bave dizajnom baze, cini mi se da ce im ovakvi thread-ovi biti daleko korisniji nego kako da iz jedne tabele join-raju drugu... to vec mogu naci i preko googl-a.

Pozdrav svima