SQL Server - relationer hvorfor

Det bruges af optimizeren og forhindrer at invalide data bliver lagt ind, f.eks. at du ikke lægger et postnummer ind i en adresse uden postnummeret findes i en postnummer-tabel.

kan godt se logikken, men tjekeks der så inden der lægges i databasen og postnummeret findes ?. dvs man laver en select inden man update/insert ?

Tja... der laves vel en slags "skjult" select - du får i hvert fald en fejlkode hvis du prøver at indsætte en værdi der ikke kan relateres til den anden tabel. Det koster lidt performance, men man kan jo bare slå relationerne fra når man er færdig med at udvikle sin applikation og ved at alt fungerer efter hensigten.

Du kan ikke undgå at lave relationer hvis du laver WebApplikationer.

Relationer gør det nemmere for dig at kode op imod din database fordi du har den mulighed at lave views og i de views kan du udbygge din egen SQL så du ikke skal gøre det i scriptkoden...dette kan spare dig massere af tid fordi du ikke skal lave JOINS, og andet advanceret SQL!!!

Håber det hjalp lidt.

/Daniel

I en multi-tier applikation, er det vigtigt at de enkelte "lag" (tiers), eks. database- og applikationslaget udfører de rigtige opgaver, for at sikre en robust- og skalérbar applikation.

Du kunne godt vælge at lade al logik ligge i din applikation og blot lave en "dum" database uden keys, indexes o.s.v. men den holder altså ikke.

Der findes på SQL Server en række mekanismer (constraints) til at sikre konsistente data. Fremmednøgler er én af de mekanismer, på linie med eks. primary key, NOT NULL og CHECK.

En fremmednøgle er altså en måde at sikre konsistente data, mere end det er en måde at lave nemmere views eller noget du kan bruge mens du udvikler din applikation.

Prøv at søg i Books Online efter constraints og foreign keys.

Kig evt. også på http://www.15seconds.com/issue/011023.htm som beskriver n-tier løsninger.

http://courses.mbl.edu/Medical_Informatics/99.2/Outlines/Remsen/Databases/index.html
http://www.devshed.com/Server_Side/MySQL/Normal/Normal1/page1.html

http://www.computerworld.com/cwi/story/0,1199,NAV47_STO55918,00.html