---

Når man har en tabel, hvor der ikke er et felt med entydige værdier, bør man
så vælge at oprette et helt nyt felt til ID eller er det mestrigtige at
vælge en primær nøgle baseret på 2 felter, der tilsammen er entydige

---

Niels Ravn skrev:
> Når man har en tabel, hvor der ikke er et felt med entydige værdier, bør man
> så vælge at oprette et helt nyt felt til ID eller er det mestrigtige at
> vælge en primær nøgle baseret på 2 felter, der tilsammen er entydige


Man bør _altid_ have et enkelt felt med garanteret unik ID - typisk
autonummereret.

Så er der taget højde for den dag ud i fremtiden, hvor de to felter af
p.t. ukendte årsager _ikke_ tilsammen er unikke. Det sker naturligvis
ikke, men alligevel

---

"Niels Ravn" <nej tak> wrote:

> Når man har en tabel, hvor der ikke er et felt med entydige værdier, bør
> man så vælge at oprette et helt nyt felt til ID eller er det mest rigtige
> at vælge en primær nøgle baseret på 2 felter, der tilsammen er entydige

Hvis du ikke har brug for at identificere en enkelt record som f.eks.
WHERE <something>='nøgle'
så er oprettelse af ekstra felter med ID, indexer m.m. være total spild af
performance/plads.

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmaill.com> skrev i en meddelelse
news:4a8fddd7$0$304$14726298@news.sunsite.dk...
> "Niels Ravn" <nej tak> wrote:
>
>> Når man har en tabel, hvor der ikke er et felt med entydige værdier, bør
>> man så vælge at oprette et helt nyt felt til ID eller er det mest rigtige
>> at vælge en primær nøgle baseret på 2 felter, der tilsammen er entydige
>
> Hvis du ikke har brug for at identificere en enkelt record som f.eks.
> WHERE <something>='nøgle'
> så er oprettelse af ekstra felter med ID, indexer m.m. være total spild af
> performance/plads.

Mine tabeller er eksempelvis

Aar
ID, integer (PK)
Aar, varchar(10)
xxx
yyy

Periode
Aar, integer, (FK)
start, date
slut, date
xxx

Spørgsmålet er, om jeg i periode-tabellen skal anvende Aar og Start som
fælles primær nøgle (Der kan ikke være overlappende perioder. Der vil ikke
kunne være to perioder i samme år med samme startdato) eller om man skal
have en ID-felt som primær nøgle? eller?

---

Niels Ravn wrote:
> Spørgsmålet er, om jeg i periode-tabellen skal anvende Aar og Start som
> fælles primær nøgle (Der kan ikke være overlappende perioder. Der vil
> ikke kunne være to perioder i samme år med samme startdato) eller om man
> skal have en ID-felt som primær nøgle? eller?

Du træder ind i én af databaseverdenens ældste og mest uløste
diskussioner: Om man bør tilstræbe kunstige eller naturlige nøgler.

Personligt hører jeg til dem der mener, at man bør søge at identificere
naturlige nøgler (altså én eller flere kombinerede kolonner, der entydigt
identificerer rækken), og at man kun bør bruge autogenererede (kunstige)
nøgler som sidste udvej. Dette for på databaseniveau at sikre sig imod
dubletter - og for ikke at tilføje unødige kolonner.

Der er også folk, der indtager en hybrid holdning: De mener, at alle
tabeller skal have en autogenereret primærnøgle, men at man stadig skal
udpege en naturlig nøgle og så sætte en UNIQUE constraint på de(n) kolonne
(r), af hensyn til dataintegriteten.

--
Troels

---

Troels Arvin wrote:

> Du træder ind i én af databaseverdenens ældste og mest uløste
> diskussioner: Om man bør tilstræbe kunstige eller naturlige nøgler.

Ja, og derudover:
Skal integriteten ligge i databasen eller forretningslogikken?

(Jeg har 'rodet' med databaser siden '80, hvor integritet på databasen ikke
altid var en mulighed).

Endvidere:
Hvis integriteten (eller tjekket) alene ligger i databasen, kan man så
undvære integritetstjek i applikationen (hint: bail-out
procedure/brugervenlighed)?

--
Med venlig hilsen
Stig Johansen

---

Gert Krabsen wrote:
> Man bør _altid_ have et enkelt felt med garanteret unik ID - typisk
> autonummereret.

En så kategorisk udtalelse er ikke særlig hensigtsmæssig, når der er tale
om, der findes meget forskellige skoler på dette område.


> Så er der taget højde for den dag ud i fremtiden, hvor de to felter af
> p.t. ukendte årsager _ikke_ tilsammen er unikke. Det sker naturligvis
> ikke, men alligevel

Hvis du sørger for, at der er primærnøgle på de to felter, der er nævnt i
den indledende beskrivelse, så kan det rent faktisk ikke lade sig gøre
(man får en fejl). Og så fanger du problemet up-front, i stedet for
potentielt at lade det ligge og ulme længe, indtil en dag, hvor en
stakkel (sandsynligvis ikke den, som skabte systemet) så får tjansen med
at rydde op.

--
Troels

---

Stig Johansen wrote:
> Ja, og derudover:
> Skal integriteten ligge i databasen eller forretningslogikken?

Personligt synes jeg, at det skal være en blanding: Fuldstændig
ufravigelige integritetskrav skal håndhæves af databasen, i fald den kan
(der kan være integritetskrav som er for komplekse til at det giver
mening, eller som kræver informationer fra andre systemer). Andre krav
kan passende håndhæves i applikationen.


> Hvis integriteten (eller tjekket) alene ligger i databasen, kan man så
> undvære integritetstjek i applikationen (hint: bail-out
> procedure/brugervenlighed)?

Ideelt set burde en applikation kunne undersøge, hvilke krav der er
defineret i databasen og så - af brugervenlighedsmæssige grunde -
håndhæve dem så tæt på brugeren som muligt. Men i praksis er
applikationsudviklingsværktøjerne almindeligvis ikke kloge nok til dette;
resultatet er, at man enten skal lægge et vist arbejde i god
fejlhåndtering eller evt. kode integritetshåndtering ind både i databasen
og applikationen.

Det, som jeg synes er vigtigt at holde sig for øje:

- Data lever typisk meget længe, hvorimod applikations-frameworks
udskiftes meget hyppigt.

- Visse typer integritetskrav kan udtrykkes meget mere forståeligt
og præcist i deklarativ form i en database, i modsætning til
i applikationskoden.

- Jo mere du fortæller databasen om sammenhænge i dens data,
desto mere effektivt kan den håndtere data. Hvis du fx
sætter en CHECK-contraint (x IN 1,2,3) på en heltals-kolonne,
kan databasen, hvis den er klog nok, bruge det til
lynhurtigt at returnere et tomt resultatsæt for
SELECT ... WHERE x=5. "Semantic query optimization".

- Datakvalitet er vigtigt. Desværre er det sjældent den
sjuskede udvikler, der skal rydde op efter sloppy
integritetshåndtering: Det er derimod ofte noget som
sker flere år efter, hvor udvikleren forlængst er
afløst af en ny person, der så får den utaknemmelige
opgave med at forstå, hvad hulen der er gang i.

--
Troels

---

Troels Arvin <troels@arvin.dk> wrote in news:h6pcns$p0m$2@news.net.uni-
c.dk:

> - Data lever typisk meget længe, hvorimod applikations-frameworks
> udskiftes meget hyppigt.

Og netop derfor bør man bruge al den tid der er nødvendig for at få en
ordentligt gennemtænkt datamodel og et fornuftigt og gennemskueligt
databasedesign som noget af det allerførste når man udvikler en
applikation.

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

---

Niels Ravn wrote:
> Når man har en tabel, hvor der ikke er et felt med entydige værdier, bør man
> så vælge at oprette et helt nyt felt til ID eller er det mestrigtige at
> vælge en primær nøgle baseret på 2 felter, der tilsammen er entydige

Som allerede antydet i andre dele af tråden så er der
stærkt delte meninger omkring at bruge en værdi fra
domænet (natural key) eller en id (surrogate key).

Hvis du spørger 10 forskellige personer om dette,
så får du 11 forskellige svar.

Personligt fortrækker jeg natural keys, men med
mange undtagelser. Jeg ville bruge et genereret id
hvis alternativet er en sammensat nøgle eller hvis
data skal tilgåes via en O/R-mapper. Dette er ikke
af database mæssige årrsager men udfra applikations
mæssige årsager.

I dit tilfælde ville jeg altså foretrække id.

Men bemærk at hvis din tabel er en del af et
større system, så bør du følge konventionen i dette.
Konsistens hjælper til at gøre det nemmere at
få overblik over systemet.

Arne