**[laessoe]** skrev:
> Jo tak! En bog eller et hæfte kunne være godt!?
Jeg kan anbefale Joakim Dalbys "Databasehåndbogen". Den er ikke
specifikt rettet mod noget databaseprogram (hvad jeg ser som en
fordel), men viser og beskriver bl.a. normalisering af databaser
(1. til 5. normalform plus Boyce-Codd er gennemgået).
>> <option value="<%= rs("firmaID") %>"><%= rs("firmanavn")
>> > %></option>
>
> Den kan jeg godt følge - pånær > ??
Det er din editor (dvs. HTML.dk) der fejlfortolker et tegn i mit
indlæg. I midten af eksemplet skal der stå
<%= rs("firmanavn") %>
- hvad der også gør i det sidste indlæg jeg skrev. Men på grund af
linjeombrydningen er tegnsekvensen "%>" havnet først på en linje.
Det kan html.dk åbenbart ikke finde ud af.
> Hvad i sætningen indikerer at det er firmanavn og ikke firmaÍd
> der skal hentes?
Begge dele hentes til select-boksen. Id-værdien bruges som skjult
værdi, mens firmanavnet bruges som vist værdi. I html-koden kan det
fx blive til
<option value="34">Irma Lyngby</option>
<option value="36">Irma Smørum</option>
...
I en browser er det kun tekstværdierne man kan se - men når du
submitter formen er det kun value-værdierne der sendes (og kun dem
der er selected).
> Så kommer det ene firma til at hedde - eks. IRMA Købehavn og
> det andet IRMA Lyngby. Men ville det ikke være samme suppe
> hvis du bruger Id til at hente firmaerne? Altså, Id (som jo er
> usynlig) henter IRMA og IRMA ---?
Pointen er at de har hver deres id-nummer. Prøv fx at søge på
"Fona" på krak.dk. Der er et hav af opslag med samme navn - men
fordi de har hver deres id-nummer kan man stadig skille dem ad.'
Visuelt kan man skille dem ad fordi de har forskellige adresser,
men det er upraktisk at skulle identificere dem på mere end ét
felt. Hvis du klikker på RET-ikonet for to forskellige opslag, kan
du se Krak identificerer dem med parameteren knr=[tal].
Når man arbejder med relationelle databaser, kommer man ofte
(næsten altid) ud for at arbejde med relaterede tabeller. Hvis en
tabel refererer til en anden tabel gøres det ved hjælp nøgler -
primærnøglen fra den overordnede tabel (fx cder) bliver
fremmednøgle i den underordnede tabel (fx numre).
I en database med mange relationer, vil primærnøglerne fra
forskellige tabeller derfor ofte optræde mange steder som
fremmednøgler. Normalisering af databaser handler om at fjerne
redundante oplysninger - alle oplysninger skal i princippet kun stå
ét sted. Et hovedproblem ved redundans er at man risikerer at have
flere forskellige oplysninger stående om den samme egenskab. Hvis
telefonnummeret på Irma i Gentofte fx er registreret tre
forskellige steder i samme database, kan man komme ud for at kun
det ene af dem opdateres.
Primærnøglerne er nødt til at stå flere steder - ellers kan man
ikke binde tabellerne sammen. Derfor bør primærnøgler altid være
fuldstændig statiske - altså noget der ikke ændrer sig over tid. En
nem måde at sikre det på er at benytte en nøgle der ikke gemmer
nogen anden information, som regel at autonummer. Hvis man fx
bruger firmanavn eller telefonnummer som primærnøgle, løber man en
risiko for at primærnøglen skal opdateres - det er ikke godt.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på
http://usenet.dk/netikette/citatteknik.html