---

Hvordan er jeres holdning til at man opdaterer i den primære nøgle i en
databasetabel?

Lad os eksempelvis sige at man ønsker at bruge cpr-nr som nøgle i en tabel.

Bør man lade cpr-nummeret være primær nøglen til tabellen (værdien er unik,
ingen dubletter her)?

Eller bør man oprette et "dummy-felt" (f.eks. en heltal, som optælles ved
hver gang en ny post oprettes) og bruge dette felt som primær nøgle og
derimod blot oprette en indeks på cpr-nr feltet (et cpr-nr KAN ændre værdi
og stadig referere til samme person, f.eks. ved kønsskifte og i forbindelse
med indvandrere)?

-------
Tomas

---

On Sun, 15 Jun 2003 00:10:11 +0200, "Tomas Christiansen"
<toc-01-nospam@blikroer.dk> wrote:

>Lad os eksempelvis sige at man ønsker at bruge cpr-nr som nøgle i en tabel.
>
>Bør man lade cpr-nummeret være primær nøglen til tabellen (værdien er unik,
>ingen dubletter her)?

Jeg vil anbefale at man har et id-felt, der ikke har nogen som helst
egenværdi, udover at være unik. Et CPR-nummer vil i praksis relatere
til én instans af én person.

Det lyder måske ellers fint nok, men lad os sige, at der er tale om en
medarbejdertabel, og medarbejderen stopper. Tre år senere starter
medarbejderen på ny, i praksis som ny medarbejder. Der ligger måske
stadigvæk historisk information omkring hans første ansættelse, men
det er ikke relevant for nyansættelsen.

I andre tilfælde kan det selvfølgelig være relevant netop at have
denne tilknytning som udgangspunkt.

--
- Peter Brodersen

---

Peter Brodersen skrev:
> Jeg vil anbefale at man har et id-felt, der ikke har nogen som helst
> egenværdi, udover at være unik.

Kan du uddybe præcis hvorfor?
Kan du komme med nogle argumenter med "gennemslagskraft"?

> Et CPR-nummer vil i praksis relatere til én instans af én person.
>
> Det lyder måske ellers fint nok, men lad os sige, at der er tale om en
> medarbejdertabel, og medarbejderen stopper. Tre år senere starter
> medarbejderen på ny, i praksis som ny medarbejder. Der ligger måske
> stadigvæk historisk information omkring hans første ansættelse, men
> det er ikke relevant for nyansættelsen.

Jo, men da man altid vil formode at et cprnr er unikt, vil man altid oprette
unikke indekser på cprnr-felter, og overalt i systemet forvente at finde én
og kun én forekomst at et givent cprnr et vilkårligt sted. Det eneste sted,
hvor jeg kan se, at der vil kunne forekomme flere instanser af samme cprnr,
vil være hvis man har en historik-tabel, og her vil man (forhåbentlig) ikke
kunne finde på at bruge cprnr som primær-nøgle (det bliver noget med en
sammensat nøgle).

-------
Tomas

---

"Tomas Christiansen" <toc-01-nospam@blikroer.dk> wrote in message
news:bcg6di$11as$1@news.cybercity.dk...
> Hvordan er jeres holdning til at man opdaterer i den primære nøgle i
en
> databasetabel?

Det tror jeg generelt er en dårlig ide. Man bør designe således at
behovet ikke opstår.

> Lad os eksempelvis sige at man ønsker at bruge cpr-nr som nøgle i en
tabel.
>
> Bør man lade cpr-nummeret være primær nøglen til tabellen (værdien
er unik,
> ingen dubletter her)?
>
> Eller bør man oprette et "dummy-felt" (f.eks. en heltal, som
optælles ved
> hver gang en ny post oprettes) og bruge dette felt som primær nøgle
og
> derimod blot oprette en indeks på cpr-nr feltet (et cpr-nr KAN ændre
værdi
> og stadig referere til samme person, f.eks. ved kønsskifte og i
forbindelse
> med indvandrere)?

Jeg ville oprette et løbenummer som primærnøgle og lade cpr være
unique. Brugere af systemet skal ikke nødvendigvis have adgang til
eller se det interne løbenummer(den fysiske implementation) men opleve
cpr-nr som record-id(logiske datamodel).

Du vil opleve at der kan være stærke holdninger for eller imod
naturlige nøgler(f.eks cpr-nr) kontra "plastiknøgler" (id der ikke
har nogem egenværdi som Brodersen siger).
Jeg tror på at man skal vælge det ene eller det andet, men ikke en
blanding. Dvs fra starten skal man lave et godt design og en standard
for fysisk implementation af datamodellen. Så løber man ind i færrest
problemer.
Jeg har arbejdet på et system der gennem 5 år konstant har været under
udvikling og forandring. Nogle år har vi måske sendt 20+
databaseopdateringer ud til kunderne. Det er fra starten designet
således at alle tabeller, uden undtagelse, har en primærnøgle der hed
<tabelnavn>_recnum medfortløbende id, samt to yderligere felter og et
par standard triggers. Jeg lavede en pl/sql -procedure (oracle) som
tager sig af de trivelle detaljer og som alle udviklere skal kalde når
de opretter en ny tabel/view/whatever.
Når et system knopskyder konstant i 5 år så kommer man undervejs ud i
noget "snavs", tvivlsomme design beslutninger, fantasifulde udviklere
der lige skal prøve en ny ide, eller bare udviklere under hårdt
tidspres der skyder genvej. Systemet kan blive noget uoverskueligt og
svært at vedligeholde, men hvis man fra starten har en standard,
selvom den kan opleves som "dum" og selvom den ikke altid bliver
fulgt, så har systemet større chance for at overleve.

Shit- hvorfor er der ikke bare een af mine 45 tv-kanaler der viser
Le-Mans?

/Peter

---

Peter Laursen skrev:
> Jeg ville oprette et løbenummer som primærnøgle og lade cpr være
> unique.

Ja, men _hvorfor_?
Hvad er det du opnår ved at gøre dette?

> Du vil opleve at der kan være stærke holdninger for eller imod
> naturlige nøgler(f.eks cpr-nr) kontra "plastiknøgler" (id der ikke
> har nogem egenværdi som Brodersen siger).

Hvem er det nu liiige at Brodersen er?

> Jeg tror på at man skal vælge det ene eller det andet, men ikke en
> blanding. Dvs fra starten skal man lave et godt design og en standard
> for fysisk implementation af datamodellen. Så løber man ind i færrest
> problemer.

Helt enig.

> således at alle tabeller, uden undtagelse, har en primærnøgle der hed
> <tabelnavn>_recnum medfortløbende id, ...
> Når et system knopskyder konstant i 5 år

Når du tænker på hvad der er sket i de 5 år, hvilken betydning har denne
"plastiknøgle" så haft set i forhold til hvis den ikke var der?
Har det overhovedet gjort nogen forskel i praksis?
Bliver plastiknøglen brug nogen steder til noget som helst?

> Shit- hvorfor er der ikke bare een af mine 45 tv-kanaler der viser
> Le-Mans?

Fordi du mangler den 46. kanal?

-------
Tomas

---

"Tomas Christiansen" <toc-01-nospam@blikroer.dk> wrote in message
news:bcima8$jdd$1@news.cybercity.dk...
> Peter Laursen skrev:
> > Jeg ville oprette et løbenummer som primærnøgle og lade cpr være
> > unique.
>
> Ja, men _hvorfor_?

På mistanke Jeg har ingen konkret erfaring med at bruge cpr-nr som
nøgle.
For at følge en standard i systemet der siger at alle tabeller skal
have en plastiknøgle og at alle andre felter er entitetens egenskaber
i den "fysiske implementation" af datamodellen. Cpr-nr ville
selvfølgelig være defineret som unique og på skærmbilleder og
kommunikation med eksterne systemer ville cpr-nr blive brugt, aldrig
plastiknøglen.

> Hvad er det du opnår ved at gøre dette?

Ungår risiko for at skulle opdatere i en primærnøgle.
Ved at følge en standard minimeres antallet af "undtagelser" i et
system. Disse undtagelser, anomaliteter, er meget ofte årsag til fejl.

> Hvem er det nu liiige at Brodersen er?

Peter Brodersen som svarede på dit indlæg lige før mig

> > således at alle tabeller, uden undtagelse, har en primærnøgle der
hed
> > <tabelnavn>_recnum medfortløbende id, ...
> > Når et system knopskyder konstant i 5 år
>
> Når du tænker på hvad der er sket i de 5 år, hvilken betydning har
denne
> "plastiknøgle" så haft set i forhold til hvis den ikke var der?
> Har det overhovedet gjort nogen forskel i praksis?

Ja, det tror jeg. Mange tabeller har udover plastiknøglen et eller
flere unikke felter, f.eks et id-nummer udstedt af en eller anden
myndighed og et navn. Data i disse unikke felter er blevet ændret
utallige gange som følge af fejlindtastning, brugere der vil ændre
deres navnestandarder, fejlagtige data i forbindelse med kommunikation
med andre systemer, programfejl, ændret lovgivning, konvertering til
nye versioner af programmer osv. Når der er behov for disse ændringer
så er det nemt at se hvilke records der hører sammen i
fremmednøglerelationer på grund af at plastiknøglen aldrig bliver
manipuleret.
I forhold til cpr-nr diskussionen svarer det til at cpr-nr for en
person ændres mange gange, ændrer internt format, ændrer betydning
eller afløses af en anden form for id.

> Bliver plastiknøglen brug nogen steder til noget som helst?

Ja da! Nøglen bliver f.eks. brugt i alle joins i sql sætninger. Nøglen
bliver også altid brugt internt af applikationerne som id på den
enkelte record.

Er du studerende eller i gang med et konkret system?

Peter

---

Peter Laursen skrev.
> > Hvem er det nu liiige at Brodersen er?
> Peter Brodersen som svarede på dit indlæg lige før mig

*KLASK* (lyden af min håndflade som rammer min pande - hårdt!)


> Ja, det tror jeg. Mange tabeller har udover plastiknøglen et eller
> flere unikke felter, f.eks et id-nummer udstedt af en eller anden
> myndighed og et navn. Data i disse unikke felter er blevet ændret
> utallige gange som følge af fejlindtastning, brugere der vil ændre
> deres navnestandarder, fejlagtige data i forbindelse med kommunikation
> med andre systemer, programfejl, ændret lovgivning, konvertering til
> nye versioner af programmer osv. Når der er behov for disse ændringer
> så er det nemt at se hvilke records der hører sammen i
> fremmednøglerelationer på grund af at plastiknøglen aldrig bliver
> manipuleret.

Vil det sige at du bruger altid plastiknøglen som reference (fremmednøgle),
selvom brugerne f.eks. ser cpr-nummeret som referencen?
Jeg kan godt se at der kunne være nogle fordele i at gøre det på den måde.

> I forhold til cpr-nr diskussionen svarer det til at cpr-nr for en
> person ændres mange gange, ændrer internt format, ændrer betydning
> eller afløses af en anden form for id.

Ja, det kan jeg se kan være en fordel, men det er _ret_ sjældent at
cpr-nummeret ændrer format!

> > Bliver plastiknøglen brug nogen steder til noget som helst?
>
> Ja da! Nøglen bliver f.eks. brugt i alle joins i sql sætninger. Nøglen
> bliver også altid brugt internt af applikationerne som id på den
> enkelte record.

Bruges i joins - fordi plastiknøglen er den der altid udgør referencen
mellem tabellerne?

> Er du studerende eller i gang med et konkret system?

HAR været!

Jeg har læst datalogi på DIKU, og der brugte vi den omtalte bog af Date.
Har fundet bogen frem af mine gemmer i forbindelse med et konkret system som
skal implementeres. Et af de store problemer er at der er tale om en gradvis
omskrivning af et eksisterende system, og i det system er der på ingen måde
tale om nogen som helst former for normalisering af data.

Systemet er udviklet på en netværksdatabase og portet direkte (så direkte
som man nu kan) til en relationel database, og med et lag imellem database
og applikationerne (programmet i C++) som skjuler det forhold at der nu
køres på anden database. Desuden tror applikationerne at de stadig kører på
en mini-computer med VT100-skærme, men i virkeligheden kører de på Windows
2000 under Citrix Metaframe og bruger almindelige Windows vinduer.

Med andre ord: Det bliver et helvede at skulle udvikle og vedligeholde et
nyt system, som af flere grunde er nødt til at være tæt knyttet (på
databaseniveau) til et gammelt, uddateret system, som stadig skal
vedligeholdes i mange år endnu...

-------
Tomas

---

"Tomas Christiansen" <toc-01-nospam@blikroer.dk> writes:

> Ja, det kan jeg se kan være en fordel, men det er _ret_ sjældent at
> cpr-nummeret ændrer format!

Hvis du bruger CPR-nummer som nøgle, skal du lige være sikker på at
det er i orden med Registertilsynet.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Thorbjoern Ravn Andersen skrev:
> Hvis du bruger CPR-nummer som nøgle, skal du lige være sikker på at
> det er i orden med Registertilsynet.

Tro mig: Det ER det!

-------
Tomas

---

"Tomas Christiansen" <toc-01-nospam@blikroer.dk> writes:

> > Hvis du bruger CPR-nummer som nøgle, skal du lige være sikker på at
> > det er i orden med Registertilsynet.
>
> Tro mig: Det ER det!

Det gør jeg skam gerne. Det er bare ikke alle der ved at man skal
være _MEGET_ forsigtig med at bruge CPR-numre til noget som helst.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Thorbjoern Ravn Andersen skrev:
> Det er bare ikke alle der ved at man skal være
> _MEGET_ forsigtig med at bruge CPR-numre til noget som helst.

Vi _har_ edb-revisorer med på banen. Så er der jo altid nogen at skyde
skylden på, hvis...

Nej, spøg til side: Det er en alvorlog problematik, som man ikke må tage let
på.
Der er uden tvivl risiko for at hele molevitten bliver lukket, hvis man ikke
overholder registerloven + de øvrige love, cirkulærer osv. osv. som vi er
underlagt.

-------
Tomas

---

"Tomas Christiansen" <toc-01-nospam@blikroer.dk> wrote in message
news:bcjttu$1ll5$1@news.cybercity.dk...
>
> Vil det sige at du bruger altid plastiknøglen som reference
(fremmednøgle),
> selvom brugerne f.eks. ser cpr-nummeret som referencen?
> Jeg kan godt se at der kunne være nogle fordele i at gøre det på den
måde.

Ja, alle fremmednøgler skal referere til en primærnøgle, så det er dem
der binder alle tabeller sammen.

> Med andre ord: Det bliver et helvede at skulle udvikle og
vedligeholde et
> nyt system, som af flere grunde er nødt til at være tæt knyttet (på
> databaseniveau) til et gammelt, uddateret system, som stadig skal
> vedligeholdes i mange år endnu...
>

Wow, du løber vist ind i mere alvorlige designbeslutninger end
hvorvidt cpr-nr kan/skal være primærnøgle. Spændende opgave!
Er du til OO? Så se måske http://www.agiledata.org/

Peter

---

Peter Laursen skrev:
> Ja, alle fremmednøgler skal referere til en primærnøgle, så det er dem
> der binder alle tabeller sammen.

Jo, jeg var bare ikke lige først klar over at du rent faktisk bruger
plastiknøglerne til noget så formuftigt. Så er det vel næsten forkert at
kalde det plastiknøgler... ?

> Wow, du løber vist ind i mere alvorlige designbeslutninger end
> hvorvidt cpr-nr kan/skal være primærnøgle. Spændende opgave!
> Er du til OO? Så se måske http://www.agiledata.org/

....og så har du kun fået indblik i et lille hjørne af problemstillingerne -
der er endnu flere komplikationer forbundet med opgaven...

Sagen er at jeg ikke skal være primær person i denne opgave, men vil komme
til spille en ikke-uvæsentlig rolle.

Spørgsmålet om cprnr er ikke bare et spørgsmål om cprnr, men en helt
grundlæggende, fundamental, vital beslutning som skal tages _inden_ vi går i
gang med at kode!

-------
Tomas

---

On Sun, 15 Jun 2003 00:10:11 +0200, Tomas Christiansen wrote:

> Bør man lade cpr-nummeret være primær nøglen til tabellen (værdien
> er unik, ingen dubletter her)?

Lige netop mht. CPR-nummer skal man passe på, har jeg hørt: Det viser
sig, at folk godt kan skifte CPR-nummer.

Dels er der angiveligt situationer, hvor fx. studerende ankommer til
landet og får et midlertidigt CPR-nummer, som så senere ændres til et
"rigtigt" ditto.

Desuden antager jeg, at folk, der måtte få kønsskifteoperation vel
også får et nyt CPR-nummer(?).

Jeg synes, at brug af naturlige primærnøgler er fint. Hvis det altså
virkelig er en naturlig og skudsikker primærnøgle.

/Troels

---

Troels Arvin skrev:
> > Bør man lade cpr-nummeret være primær nøglen til tabellen (værdien
> > er unik, ingen dubletter her)?
>
> Lige netop mht. CPR-nummer skal man passe på, har jeg hørt: Det viser
> sig, at folk godt kan skifte CPR-nummer.

Ja, Troels, det var også derfor at jeg et par linier længere nede skrev:

"...et cpr-nr KAN ændre værdi og stadig referere til samme person, f.eks.
ved kønsskifte og i forbindelse med indvandrere.."


> Jeg synes, at brug af naturlige primærnøgler er fint. Hvis det altså
> virkelig er en naturlig og skudsikker primærnøgle.

Hvad mener du med "skudsikker"?
Det er helt "skudsikkert" at der ikke findes to mennesker med samme cprnr,
men det er ikke "skudsikkert" at et menneske beholder sig cprnr hele livet.

Lidt afhængig af kravene til systemet, vil man enten oprette det ny cprnr
som en "ny" person og "afslutte" det gamle cprnr eller man vil "omdøbe"
cprnummeret - heraf en eventuel opdatering af en primærnøgle. Hvad er din
holdning - er det ok eller ej?

-------
Tomas

---

On Sun, 15 Jun 2003 22:40:19 +0200, Tomas Christiansen wrote:

> Ja, Troels, det var også derfor at jeg et par linier længere nede skrev:
>
> "...et cpr-nr KAN ændre værdi og stadig referere til samme person, f.eks.
> ved kønsskifte og i forbindelse med indvandrere.."

Ups, det havde jeg ikke set.

Jeg kan ikke se, at CPR nummer kan bruges som primærnøgle, hvis den ikke
unikt identificerer en person.

/Troels

---

Troels Arvin skrev:
> Jeg kan ikke se, at CPR nummer kan bruges som primærnøgle, hvis den ikke
> unikt identificerer en person.

På et givent tidspunkt i tiden vil et givent (eksisterende) cprnr altid
unikt referere til en person.

Der er blot intet i vejen for at det på et andet tidspunkt er et andet cprnr
som unikt refererer til samme person...

-------
Tomas

---

Tomas Christiansen wrote:
> På et givent tidspunkt i tiden vil et givent (eksisterende) cprnr altid
> unikt referere til en person.

Og her løber du så ind i den sædvanlige problemstilling omkring historik -
hvor meget historik skal man kunne se i systemet? De fleste sagsbehandlere
kræver historik.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

---

Lars Dybdahl skrev:
> > På et givent tidspunkt i tiden vil et givent (eksisterende) cprnr altid
> > unikt referere til en person.
>
> Og her løber du så ind i den sædvanlige problemstilling omkring historik -
> hvor meget historik skal man kunne se i systemet? De fleste sagsbehandlere
> kræver historik.

Ja, du har ganske ret.
Brugerne er dog ikke forvente med historik som systemet er i dag. Det er
næsten ikke-eksisterende.

-------
Tomas

---

Tomas Christiansen wrote:
> Hvordan er jeres holdning til at man opdaterer i den primære nøgle i en
> databasetabel?

Helt fint. Hvis vi tager en postnummer tabel som eksempel, så bliver du
alligevel nødt til at have postnummeret stående mange steder i din database
for at kunne indeksere feltet sammen med de andre felter, der indgår i dine
SQL forespørgsler. F.eks.:

select navn,postnr
from personliste
where postnr=2800
order by navn

Denne forespørgsel ville ikke kunne fungere hensigtsmæssigt på en stor
datamængde, hvis navn og postnr felterne lå i hver deres tabel, da der så
ikke vil være et fornuftigt index at benytte. Da du så alligevel skal have
postnr mange forskellige steder, kan du lige så godt bruge postnr som
primær nøgle i postnummertabellen.

Jeg kan i øvrigt oplyse, at det også er sådan de fleste databaser er
opbygget. F.eks. indeholder et nærved liggende atomkraftværks
vedligeholdsdatabase mange tabeller med adskillige informationsbærende
felter i den primære nøgle.

Jeg er lidt i tvivl om netop CPR-Nummeret - da du skal sikre adgangen til
CPR-Nummer væsentligt mere end du skal sikre adgangen til de fleste andre
typer data, kan det ofte være meget hensigtsmæssigt at opfinde et nyt
person-nummer system, som ikke relaterer til CPR på nogen måde, og så bruge
det person-nummer system til at indexere og søge i databasen. Det
forhindrer dig ikke i at lave en brugerflade, hvor du kan slå en person op
vha. CPR-nummer, men giver dig samtidig adgang til at publicere nogle views
på person-niveau ind i databasen, der er rimelig anonymiseret.

Hilsen,

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

---

Lars Dybdahl skrev:
> Helt fint. Hvis vi tager en postnummer tabel som eksempel, så bliver du
> alligevel nødt til at have postnummeret stående mange steder i din
database
> for at kunne indeksere feltet sammen med de andre felter, der indgår i
dine
> SQL forespørgsler.

Ja og nej.
Man KAN jo have en anden værdi stående (en fremmednøgle), som refererer til
tuplen med postnummeret i postnummertabellen.
Derved vil man kunne omdøbe et postnummer ved blot at skulle opdatere ét
eneste sted.

> Jeg kan i øvrigt oplyse, at det også er sådan de fleste databaser er
> opbygget. F.eks. indeholder et nærved liggende atomkraftværks
> vedligeholdsdatabase mange tabeller med adskillige informationsbærende
> felter i den primære nøgle.

Ja, hvis man læser C. J. Date's bog Database Systems (5. udgave og
tidligere), er der meget strenge krav til at primærnøglen rent faktisk SKAL
bruges til noget fornuftigt. Hele primærnøglen eller dele af den (ved
sammensatte felter) må ikke kunne undværes eller kunne være null. Det
strider jo direkte mod idéen om at lade primærnøglen være et tilfældigt tal
(f.eks. ved brug af en sequenser).

> Jeg er lidt i tvivl om netop CPR-Nummeret - da du skal sikre adgangen til
> CPR-Nummer væsentligt mere end du skal sikre adgangen til de fleste andre
> typer data, kan det ofte være meget hensigtsmæssigt at opfinde et nyt
> person-nummer system,

Nej, ikke i dette system.
På alle papirer, i alle registre, kort sagt OVERALT er der "plastret" til
med cprnumrene.
Der skal IKKE opfindes et nyt cprnr-system!

-------
Tomas

---

"Tomas Christiansen" <toc-01-nospam@blikroer.dk> wrote in message
news:bcilvd$j8t$1@news.cybercity.dk...
> Ja, hvis man læser C. J. Date's bog Database Systems (5. udgave og
> tidligere), er der meget strenge krav til at primærnøglen rent
faktisk SKAL
> bruges til noget fornuftigt. Hele primærnøglen eller dele af den
(ved
> sammensatte felter) må ikke kunne undværes eller kunne være null.
Det
> strider jo direkte mod idéen om at lade primærnøglen være et
tilfældigt tal
> (f.eks. ved brug af en sequenser).

Jeg har altid opfattet det sådan at Date snakker om "den relationelle
model", som er en formel teoretisk verden. Når man implementerer et
system i et eller eller andet databaseprodukt så bruger man sin sunde
fornuft og følger "almindelig god praksis" hvad det så end er. Man
bruger jo heller ikke relationel algebra på sine data

Kender du Database Debunkings? http://www.pgro.uk7.net/index.htm Søg
f.eks på surrogate keys

Her skriver Date f.eks i http://www.pgro.uk7.net/on_pks.htm
"Chris Date Responds: (...) I also agree that introducing an
artificial, surrogate, nonvolatile key will often be a good idea.
However (...)"

Peter

---

Peter Laursen skrev:
> Jeg har altid opfattet det sådan at Date snakker om "den relationelle
> model", som er en formel teoretisk verden. Når man implementerer et
> system i et eller eller andet databaseprodukt så bruger man sin sunde
> fornuft og følger "almindelig god praksis" hvad det så end er. Man
> bruger jo heller ikke relationel algebra på sine data
>
> Kender du Database Debunkings? http://www.pgro.uk7.net/index.htm Søg
> f.eks på surrogate keys
>
> Her skriver Date f.eks i http://www.pgro.uk7.net/on_pks.htm
> "Chris Date Responds: (...) I also agree that introducing an
> artificial, surrogate, nonvolatile key will often be a good idea.
> However (...)"

Jeg vil med stor interesse kigge på dine links.
SFL (Send Flere Links) hvis du har dem

-------
Tomas

---

Tomas Christiansen wrote:

>> alligevel nødt til at have postnummeret stående mange steder i din
> database
>> for at kunne indeksere feltet sammen med de andre felter, der indgår i
> dine
> Man KAN jo have en anden værdi stående (en fremmednøgle), som refererer
> til tuplen med postnummeret i postnummertabellen.

Jeg tror vist jeg skrev et dårligt eksempel på et SQL statement. Jeg ville
have skrevet:

select navn,postnr
from personliste
order by postnr,navn

De fleste database systemer kan ikke lave et indeks på mere end en tabel ad
gangen. Hvis du derfor ikke har et postnummerfelt i samme tabel som
navnefeltet, skal databasen sortere navnene manuelt i memory inden den kan
levere første record. Hvis du har 100.000 mennesker på et enkelt
postnummer, skal den altså rode rundt med 100.000 records i memory før den
første af disse 100.000 records kan leveres. Det kræver mindst 100.000
læseadgange til databasen, og man kan nemt risikere 8 millioner
læseadgange, før den første record kan leveres.

Hvis du derimod har postnr og navn i samme tabel, skal den bare slå op i
indekset med postnr+navn, og begynde at levere records sekventielt i
henhold til dette indeks. Det kræver mindst 1 læseadgang til databasen og
normalt max 25 læseadgange (ved en befolkningsstørrelse som Danmarks). 25
læseadgange før første record leveres er væsentligt hurtigere end 8.000.000
læseadgange. Det er derfor, at jeg siger, at du skal sørge for at have
redundans i din implementering, og at datamodellen sjældent kan bruges som
databasestruktur, da datamodellen er normaliseret.

> Ja, hvis man læser C. J. Date's bog Database Systems (5. udgave og
> tidligere), er der meget strenge krav til at primærnøglen rent faktisk
> SKAL bruges til noget fornuftigt.

Det lyder som en fornuftig bog Jeg har desværre i min tid set lidt for
mange lærebøger, der fokuserer for meget på datamodeller og normalisering,
og slet ikke beskæftiger sig med indekser, og ofte glemmer at fortælle
eleverne, at en datamodel ikke er helt det samme som en "fysisk"
databasestruktur.

> Nej, ikke i dette system.
> På alle papirer, i alle registre, kort sagt OVERALT er der "plastret" til
> med cprnumrene.
> Der skal IKKE opfindes et nyt cprnr-system!

Hehe... det var nu heller ikke et cprnr-system jeg mente, men bare et unikt
tal til identifikation af brugeren. F.eks. bruger firmaer ofte konceptet
"kundenummer", og jeg har selv været med til at lave databasesystemer til
offentlige kontorer, hvor vi brugte konceptet "kundenummer", selv om
databasen rent faktisk indeholdt CPR-Nummer. Kontorpersonalet slog op med
CPR-Nummer, men en del udskrifter indeholdt ikke CPR-Nummer, men indeholdt
til gengæld et unikt "kundenummer", så man både kunne publicere
udskrifterne til brug uden for kontoret, men også samtidigt kunne gå
tilbage til databasen og fremfinde en person ud fra de oplysninger, der
stod på udskriften.

Det hænder jo, at man f.eks. fra anden side bliver bedt om at levere f.eks.
listen over top 10 ressourceforbrugende klienter, så man kan analysere
situationen, og listen skal så ses af folk, der ifølge database
sikkerhedsreglerne ikke måtte have adgang til personoplysninger.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/