---

Jeg har en medlemstjeneste på nettet, hvor brugerne skal kunne søge hinanden
efter uddannelse, bopæl, livsholdning o.a. Der er 2 principielt forskellige
måder at lave medlemsdatabasen på. Den ene er, at man indsætter alle de
faktisk oplysninger om brugerne i databasen. Tabellens ID-nr. 375 kan så
have følgende felter: "Nielsen", "skolelærer", "Vanløse", "humanist",
"kæreste". Problemet er, at når man skal lave en søgefunktion på disse
oplysninger, så er der en masser æ,ø,å som gør søgningen usikker. Er det
derfor ikke bedre (som man gør f.eks. på Dating.dk) at erstatte disse
oplysninger med tal, således at man f.eks. erstatter hver af de 25
erhvervsmuligheder, som brugerne kan vælge mellem, med et tal, og i
databasen indsætter man så, i stedet for "skolelærer", tallet 8.

Det kræver så til gengæld, når man skal liste medlemmerne, at man har kode,
der omsætter disse tal til det de betyder, og det tager naturligvis lidt
tid.

Jeg kunne godt tænke mig at høre fra andre, der har syslet med dette
problem, hvad de mener er bedst. Skal man sætte de "rigtige" ord direkte ind
i databasen, og så f.eks. konvertere æøå på vejen ind og ud af db - eller
skal man hellere erstatte disse ord med simple tal, som man så konverterer
til de rigtige ord når man laver udskrift? Hvad er fordele og ulemper ved de
to metoder?

Gode råd ønskes.

v.h.
Jakob Munck

---

Du kan erstatte tallene fra databasen når du henter dem før de udskrives på
skærmen. Brug strings til dette.

If oRs("By") = 1 Then
strBy = "Aalborg"
ElseIf oRs("By") = 2 Then
strBy = "Hjørring"
ElseIf oRs("By") = 3 Then
strKat = "Skagen"
Else
strBy = "Århus"
End If


Udskriv resultatet med <%=strKat%>

Som du Sikkert allerede har gættet vil dette blilve et stort arbejde, for
der er mange byer i Danmark.

Det vil sikkert være bedre i nogle af de andre tilfælde hvor der ikke er så
mange muligheder at vælge i mellem, feks ved "Civil stand" (kærreste, ugift,
fraskilt etc).

--

Mvh / Regards

-=< Christian >=-
ICQ: 25308942
http://www.cmnielsen.dk

---

> Jeg kunne godt tænke mig at høre fra andre, der har syslet med dette
> problem, hvad de mener er bedst. Skal man sætte de "rigtige" ord direkte
ind
> i databasen, og så f.eks. konvertere æøå på vejen ind og ud af db - eller
> skal man hellere erstatte disse ord med simple tal, som man så konverterer
> til de rigtige ord når man laver udskrift? Hvad er fordele og ulemper ved
de
> to metoder?
>
> Gode råd ønskes.

Det du sysler med, høre "nok" ikke rigtig hjemme i denne gruppe, men nok
mere i dk.edb.database.*. Men det er bestemt heller ikke uvæsentligt for
denne gruppe.
Det du bør gør, er at normaliser din database. Det betyder meget forenkelt,
at for hvergang du har den samme oplysning gemt mere end engang i en tabel,
eks. "vanløse", bør dette placeres i en anden tabel, som så har et IDnumre.
IDnumre bliver så gemt i din "hovedtabel". Derved får du godt nok mange små
tabeller, så indimellem bliver man nød til sætte en grænse.

Et eks.: By og postnumre. Her er ville det kun være nødvendig at gemme
postnumre i din "hovedtabel", og i en anden tabel gemmer du så både by og
postnumre.
Håber at du har fanget ideen.
Jeg benytter mig selv af den sidste metode, for på den måde, op når jeg selv
det bedste resultat.

Allan Bach

Forslag: Hvis du bruger Acces, så prøve at lade den normaliser din database
(gem lige en kopi først inden du gør det)

---

Det er noget helt nyt for mig med "normalisering", men jeg har da prøvet det
v.hj.a. den guide, som er i Access2000. Men jeg må indrømme, at jeg ikke
forstår teorien i det og helt føler at jeg har mistet kontrollen over, hvad
jeg selv laver. Men det går måske over??

1. Kunne jeg ikke selv lave disse mange små tabeller?
2. Hvordan skal min kode laves om for at kommunikere med de mange nye
tabeller?
3. Er det sådan, at der nu løbende laves nye tabeller medens databasen
bruges?
4. Hvor finder jeg en simpel forklaring på, hvad "normalisering" er?
5. Hvis jeg erstatter alle dublikerede tekstoplysninger i databasen med tal,
så må normaliseringen da være (stort set) unødvendig. Ikke?

v.h.
Jakob Munck

---

"Jakob Munck" <jakob.munck@tdcadsl.dk> wrote in message
news:3c650d09$0$222$edfadb0f@dspool01.news.tele.dk...
> Det er noget helt nyt for mig med "normalisering", men jeg har da prøvet
det
> v.hj.a. den guide, som er i Access2000. Men jeg må indrømme, at jeg ikke
> forstår teorien i det og helt føler at jeg har mistet kontrollen over,
hvad
> jeg selv laver. Men det går måske over??

Prøv at kigge lidt på:
<http://www.devshed.com/Server_Side/MySQL/Normal/Normal1/page1.html>

> 1. Kunne jeg ikke selv lave disse mange små tabeller?

Jo, sagtens

> 2. Hvordan skal min kode laves om for at kommunikere med de mange nye
> tabeller?

I dine SQL forespørgsler skal du til at benytte Joins for at få navnet på
f.eks. en by ud.

Hvis du ikke kender noget til joins er der en fin lille introduktion her:
<http://www.w3schools.com/sql/sql_join.asp>

> 3. Er det sådan, at der nu løbende laves nye tabeller medens databasen
> bruges?

Nej det gør der ikke, du skal selv sørge for at alle "små tabeller" har alle
de nødvendige data som f.eks. alle byer og postnumre.

> 4. Hvor finder jeg en simpel forklaring på, hvad "normalisering" er?

<http://www.hedeskov.dk/netpublikationer/udv-database/kap3/kapitel3.htm>

> 5. Hvis jeg erstatter alle dublikerede tekstoplysninger i databasen med
tal,
> så må normaliseringen da være (stort set) unødvendig. Ikke?

Det ER normalisering når man flytter data fra "datatabellen" til små
satelittabeller. Der er så forskellige grader af normalisering.

--
Jakob Andersen

---

"Jakob Munck" <jakob.munck@tdcadsl.dk> skrev i en meddelelse
news:3c650d09$0$222$edfadb0f@dspool01.news.tele.dk...
> Det er noget helt nyt for mig med "normalisering", men jeg har da prøvet
det
> v.hj.a. den guide, som er i Access2000. Men jeg må indrømme, at jeg ikke
> forstår teorien i det og helt føler at jeg har mistet kontrollen over,
hvad
> jeg selv laver. Men det går måske over??
Teorie er også en svær størrelse at have med at gør. Men grundlæggende går
det ud på at fjerne redundans (ikke sikker på stave måden) fra DB
(tabeller). der findes mange gode bøger om netop disse emner (tag en tur på
biblioteket og find en bog om det. jeg mener at kunne huske, at jeg har læst
en bog af en der hed Søren ???. Vil prøve at finde den på nettet, og sende
dig et link)

> 1. Kunne jeg ikke selv lave disse mange små tabeller?
Helt klar, det er det bedste. Så har du også helt styr over hvordan det
hænger sammen
> 2. Hvordan skal min kode laves om for at kommunikere med de mange nye
> tabeller?
Dine forespørgelser bliver lidt "mere" indviklet, og du behøver nok et DB
opslag mere. Jeg kan ikke lige komme med et eks. her og nu.
> 3. Er det sådan, at der nu løbende laves nye tabeller medens databasen
> bruges?
Kender i MS Access godt nok til at kunne svare på det, men mit umiddelbart
svar må være nej
> 4. Hvor finder jeg en simpel forklaring på, hvad "normalisering" er?
Se mit forrige svar.
> 5. Hvis jeg erstatter alle dublikerede tekstoplysninger i databasen med
tal,
> så må normaliseringen da være (stort set) unødvendig. Ikke?
Nej. Fordelen ligger i, at gør det enkelte.
Eks .
Du har en tabel hvor du har følgende felter:
Navn, Adresse, Telefon, Postnr, By.

For at normalisere denne tabel, opretter du en ny tabel, hvor du har postnr
og by, med postnr som primærnøgle
Herefter fjerne du by fra den første tabel., så du nu har
Navn, Adresse, Telefon, Postnr
Derved kan du altis finde hvilken by det er, ved at forespørger i postnr
tabellen. Fordelen er, at hvis byen ændre navn, skal du kun ændre det et
sted, i postnr tabellen.
Hvis du ikke have normaliseret tabellen, skulle du rette det alle de stede,
hvor byen stå.

Allan Bach

---

Fandt følgende link.
http://www.hedeskov.dk/netpublikationer/udv-database/indhold.htm
http://www.hager.dk/noter/m0enot01.html

---

Efter at have læst de anviste links og en del andre angående "normalisering"
må jeg sige, at jeg stadig stort set ikke fatter hvad fidusen skulle være
ved dette. Jeg kan notere mig følgende på grundlag af min læsning og forsøg
med denne kunstart:

1. Normalisering kan gøre søgningen efter data mere langsom (står der i
læreteksten).

2. Databasen fylder mere efter normalisering (i mit eget eksperiment
v.hj.a. Access-automatiske funktion voksede den med 300 kb.)

3. Koden til at sætte ind og skrive ud fra en normalisert database er mere
besværlig end koden for den ikke-normaliserede.

4. Det bliver meget sværere at overskue hvor ens data befinder sig og
hvordan de forholder sig til hinanden. Relationen mellem data bliver mere
uigennemskuelig og ikke synlig, som den var før.

5. De data jeg har i min tabel bliver ikke færre fordi jeg opdeler
kolonnerne i forskellige "undertabeller". Tværtimod giver det større
datamængde.

Ja, det er min hidtidige konklusion på mine studier af dette emne.

v.h.
Jakob Munck

---

On Sat, 9 Feb 2002 22:24:53 +0100, "Jakob Munck"
<jakob.munck@tdcadsl.dk> wrote:

>Efter at have læst de anviste links og en del andre angående "normalisering"
>må jeg sige, at jeg stadig stort set ikke fatter hvad fidusen skulle være
>ved dette.

Hvis vi tage rudgangspunkt i "standard-eksemplet" med postnumrene,
synes jeg fidusen er ret indlysende:

* Du har kun Bynavn-informationen stående ét sted

* Hvis en information skal rettes, er det kun ét sted, det skal gøres.
- Hvis fx Farum besluttede, at deres by skal staves med Ph - Pharum -
så rettes det ét sted for alle registrerede, der bor i Farum.

* Det er langt sværere at komme til at skrive forkert information.
Hvis man fx kom til at skrive "Slavelse" i stedet for "Slagelse",
ville det være stort set umuligt at søge den pågældende post frem.

>Jeg kan notere mig følgende på grundlag af min læsning og forsøg
>med denne kunstart:

>1. Normalisering kan gøre søgningen efter data mere langsom (står der i
>læreteksten).

Vil jeg ikke kommentere, da der sikkert kan findes eksempler på begge
dele.

>2. Databasen fylder mere efter normalisering (i mit eget eksperiment
>v.hj.a. Access-automatiske funktion voksede den med 300 kb.)

Har du fjernet den overflødige information og komprimeret databasen
efterfølgende?

>3. Koden til at sætte ind og skrive ud fra en normalisert database er mere
>besværlig end koden for den ikke-normaliserede.

Det er rigtigt - til gengæld kan du altså genbruge de samme data i
flere sammenhænge.

>4. Det bliver meget sværere at overskue hvor ens data befinder sig og
>hvordan de forholder sig til hinanden. Relationen mellem data bliver mere
>uigennemskuelig og ikke synlig, som den var før.

Umiddelbart ja, men hvis databaserne bliver lidt mere komplekse, så
vil det ofte give et bedre overblik med en relationsdatabase frem for
en flad.

Det hører selvfølgelig med til billedet, at når man skal *bruge* sine
data, vil man sjældent kigge på de "rå" tabeller, men på en
forespørgsel eller formular, der er bygget oven over flere tabeller.
Det "smukke" i sådanne databaser er netop det at man kan designe
præcis de forespørgsler, som henter præcis de data man har behov for
og ikke alt muligt andet.

Tag fx et firma, hvor man har en database med oplynsinger om hver
medarbejders adresse, lønforhold, udleveret værktøj, bil el .lign.

Hvis det skulle løses i en flad database, ville man få:
37, Hansen - Peter, x-vej 17, 2200 København N, 16500, værktøj 1,
værktøj 2, værktøj 3, Ford Escort, PP 33.333, osv.

- skulle det udvides til også at have flere oplysninger om værktøj (fx
serienummer, fabrikat) eller biler (serviceeftersyn, skader, alder
osv.), så ville det være umuligt (eller i hvert fald højst
uhensigtsmæssigt) at holde det samlet i en flad database.

Her er relationsdatabasens styrke: Fx i en tabel over værktøj, kan du
tilnytte et brugerID - uden i øvrigt at bekymre dig om brugerens
adresse, lønforhold osv. Tabellen er altså fokuseret på at lave en
liste over værktøj, mens oplysninger om brugeren ligger i en anden
tabel. - Men de er altså bundet sammen gennem brugerID =
medarbejderID.

Det løser også det problem, som er antydet ovenfor: Hvad gør man, hvis
der i tabellen er afsat plads til, at hver medarbejder kan have 3
stykker værktøj - mens nogen har 1 eller 2 og andre pludselig får
behov for at have 4 eller 5.

>5. De data jeg har i min tabel bliver ikke færre fordi jeg opdeler
>kolonnerne i forskellige "undertabeller". Tværtimod giver det større
>datamængde.

Her er jeg til gengæld helt uenig - det vil i 99% af tilfælde ikke
være tilfældet.

Til slut: Det er klart at nogle ting bliver mere komplekse, når man
får flere værktøjer til rådighed - til gengæld kan man også langt
flere ting.

Mvh. Jørn

---

Diskussionen er temmelig teoretisk, når man ikke véd hvad det er den
såkaldte normalisering skal sættes op som alternativ til. Jeg kan kun udtale
mig ud fra den database med 10 tabller i, som jeg selv anvender på
www.get2you.dk.. Her er den største tabel den, der rummer medlemmernes
navne, brugernavne, emails, login-tidspunkt, postnummer og antal
eksponeringer. Alle de fordele der nævnes i forbindelse med normalisering
har jeg i forvejen.

1. Data er kun nævnt et sted.
2. Data har ensartet format (da indtastede data i vidt omfang omsættes til
tal)
3. Der kan ikke skrives forkert information (da der anvendes rullemenuer med
faste valgmuligheder)
4. Et medlemsdata kan let rettes uden at det påvirker andre data.
5. Databasen fylder ikke meget (mit eksperiment viser, at hvis den
normaliseres vokser den 25%)
6. En rettelse af f.eks. hvordan et bynavn staves skal kun rettes ét sted.
7. Jeg kan hente præcis de data ud af én eller flere tabeller samtidig som
jeg selv ønsker.

Jeg forstår, at der findes mange former for "normalisering" og jeg gætter
på, at det ikke altid er en fordel at gennemføre normalisering, det afhænger
af hvordan databasen ser ud i forvejen, og af hvad man mener med dette
mangetydige begreb "normalisering".

I mit tilfælde kan jeg - indtil videre - kun se ulemper ved at forsøge mig
med denne proces. Men dermed har jeg naturligvis ikke udtalt mig om alle
andre databaser end min egen.

v.h.
Jakob Munck