Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Spoljni kljucevi u MS SQL

[es] :: MS SQL :: Spoljni kljucevi u MS SQL

[ Pregleda: 6683 | Odgovora: 13 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

e5944
Rakic Vladimir
Becej

Član broj: 37118
Poruke: 255
*.stcable.co.yu.



Profil

icon Spoljni kljucevi u MS SQL20.04.2005. u 08:57 - pre 195 meseci
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ć.
 
Odgovor na temu

MilovanB
Sydney

Član broj: 61367
Poruke: 21
*.flexirent.com.



Profil

icon Re: Spoljni kljucevi u MS SQL21.06.2005. u 05:52 - pre 193 meseci
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
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.eqao.com.



+79 Profil

icon Re: Spoljni kljucevi u MS SQL22.06.2005. u 18:41 - pre 193 meseci
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.

 
Odgovor na temu

MilovanB
Sydney

Član broj: 61367
Poruke: 21
*.flexirent.com.



Profil

icon Re: Spoljni kljucevi u MS SQL23.06.2005. u 01:54 - pre 193 meseci
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.
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.eqao.com.



+79 Profil

icon Re: Spoljni kljucevi u MS SQL23.06.2005. u 14:09 - pre 193 meseci
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.

:-)
 
Odgovor na temu

majstor_01

Član broj: 60008
Poruke: 63
*.my-its.net.



Profil

icon Re: Spoljni kljucevi u MS SQL28.09.2005. u 23:51 - pre 190 meseci
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





 
Odgovor na temu

Riste Pejov
Team Leader/Senior Software Developer @
Ein-Sof ltd Skopje
Skopje, Macedonia

Član broj: 128
Poruke: 571
217.16.84.*

Jabber: richie@bagra.net.mk
ICQ: 154236769
Sajt: riste.softver.org.mk


Profil

icon Re: Spoljni kljucevi u MS SQL30.09.2005. u 00:48 - pre 190 meseci
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.


[Ovu poruku je menjao Riste Pejov dana 30.09.2005. u 01:51 GMT+1]
People who think they know everything tend to irritate those of us who do.
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.sksyu.net.



+171 Profil

icon Re: Spoljni kljucevi u MS SQL30.09.2005. u 10:26 - pre 190 meseci
Citat:

MilovanB: Kao prvo, kriscenje IDENTITY kolona u dizajniranju baze je los obicaj.


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

jablan

Član broj: 8286
Poruke: 4541



+709 Profil

icon Re: Spoljni kljucevi u MS SQL30.09.2005. u 10:36 - pre 190 meseci
Citat:
negyxo: Dobro, u redu, ali sta je alternativa kad nema realnog kljuca?

uniqueidentifier polje sa DEFAULT (newid())?
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.sksyu.net.



+171 Profil

icon Re: Spoljni kljucevi u MS SQL01.10.2005. u 07:14 - pre 190 meseci
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.


 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+709 Profil

icon Re: Spoljni kljucevi u MS SQL01.10.2005. u 10:52 - pre 190 meseci
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.

[Ovu poruku je menjao jablan dana 01.10.2005. u 12:02 GMT+1]
 
Odgovor na temu

goranvuc
Goran Vucicevic
Novi Sad

Član broj: 4934
Poruke: 1846
*.neobee.net.



+41 Profil

icon Re: Spoljni kljucevi u MS SQL01.10.2005. u 13:37 - pre 190 meseci
Citat:
jablan

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!
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.sksyu.net.



+171 Profil

icon Re: Spoljni kljucevi u MS SQL01.10.2005. u 20:25 - pre 190 meseci
@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
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.sksyu.net.



+171 Profil

icon Re: Spoljni kljucevi u MS SQL02.10.2005. u 09:30 - pre 190 meseci
Opet ja :)

Usko vezano za ovaj thread

http://www.sqlmonster.com/Uwe/...identity-column-as-primary-key


 
Odgovor na temu

[es] :: MS SQL :: Spoljni kljucevi u MS SQL

[ Pregleda: 6683 | Odgovora: 13 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.