---

Hej, jeg skal til at lave en DB (oracle). Meningen er at man skal kunne søge
i DBen ved brug af stikord. F.eks:

biler

artnr navn beskkrivelse
stikord
-----------------------------------------------------------------------
1 mercedes et eller andet bil,
mercedes, disel
2 volvo et eller andet bil,
volvo, benzin


Meningen er når brugeren f.eks. søger efter "bil" så kommer begge tupler
med. Hvis brugeren søger "bil, disel", så får han art. nr. 1 tilbage.
Endvidere skal det være muligt at opdatere "stikord" sålades at brugeren kan
slette og/eller tilføje nogle nye stikord.
Jeg har overvejet at oprette en tabel "stikord" (og relation "rel"):

stikord:

sid ord
----------------
1 bil
2 disel
3 mercdes
4 volvo
5 benzin

rel:

artnr sid
------------------
1 1
1 2
1 3
2 1
2 4
2 5

og "biler" har følgende tupler: artnr, navn, beskrivelse.

og så kan jeg søge : SELECT artnr,navn FROM biler, stikord, rel WHERE
ord=mercedes AND stikord.sid=rel.sid AND rel.artnr = biler.artnr:

Og det ser vist fint ud, men findes der en anden mulighed? Jeg får jo en
meget stor relation "rel". Skal reglen om atomiske værdier altid overoldes,
og hvis ikke, hvordan kan man have "stikord" i tabel "biler", men hvor der
samtidigt er muligt at søge og opdatere disse værdier?


mvh Dejan

---

Stranger <stranger@tdcspace.dk> wrote:

> Jeg har overvejet at oprette en tabel "stikord" (og relation "rel"):

Du skal passe på med dine ordvalg. Det der i relationsdatabaseteorien
kaldes en /relation/, det matematiske begreb for en mængde af tupler, er
det der i de fleste databaser kaldes en tabel.

Jeg bliver bare forvirret.
--
Per Erik Rønne
Frederikssundsvej 308B, DK-2700 Brønshøj, DENMARK, EUROPEAN UNION
Tlf. + fax: +38 89 00 16, mobil +45 28 23 09 92.
Homepage http://www.diku.dk/students/xerxes

---

"Per Erik Ronne" <serse@diku.dk> wrote in message
news:1f14gvw.30tiw11768kwnN%serse@diku.dk...
> Du skal passe på med dine ordvalg. Det der i relationsdatabaseteorien
> kaldes en /relation/, det matematiske begreb for en mængde af tupler, er
> det der i de fleste databaser kaldes en tabel.
>
> Jeg bliver bare forvirret.

Det er jeg også: "det der i relationsdatabaseteorien kaldes en
/relation/...er det der i de fleste databaser kaldes en tabel"???
Jeg taler også om relationelle databaser, og i det sammenhæng er disse
tabeller relationer. At jeg skrev "relation" var også med vilje idet jeg
ville understrage at der er tale om en "relationship"-sammenhæng
(mange-til-mange).


Dejan


> Per Erik Rønne
> Frederikssundsvej 308B, DK-2700 Brønshøj, DENMARK, EUROPEAN UNION
> Tlf. + fax: +38 89 00 16, mobil +45 28 23 09 92.
> Homepage http://www.diku.dk/students/xerxes

---

Stranger <stranger@tdcspace.dk> wrote:

> "Per Erik Ronne" <serse@diku.dk> wrote in message
> news:1f14gvw.30tiw11768kwnN%serse@diku.dk...
> > Du skal passe på med dine ordvalg. Det der i relationsdatabaseteorien
> > kaldes en /relation/, det matematiske begreb for en mængde af tupler, er
> > det der i de fleste databaser kaldes en tabel.
> >
> > Jeg bliver bare forvirret.
>
> Det er jeg også: "det der i relationsdatabaseteorien kaldes en
> /relation/...er det der i de fleste databaser kaldes en tabel"???
> Jeg taler også om relationelle databaser, og i det sammenhæng er disse
> tabeller relationer. At jeg skrev "relation" var også med vilje idet jeg
> ville understrage at der er tale om en "relationship"-sammenhæng
> (mange-til-mange).

Jeg skrev et passende langt svar til dig i går, men så gik maskinen
desværre ned, og MacSOUP-databasen ned. Så jeg måtte finde en backup
frem.

Men du kan finde de oplysninger jeg ville have givet dig, i et svar jeg
netop udførligt har givet en anden, i en anden tråd her i gruppen,
omhandlende Oracle. Som bliver sendt samtidig med dette.
--
Per Erik Rønne
Frederikssundsvej 308B, DK-2700 Brønshøj, DENMARK, EUROPEAN UNION
Tlf. + fax: +38 89 00 16, mobil +45 28 23 09 92.
Homepage http://www.diku.dk/students/xerxes

---

Stranger wrote:
>
> "Per Erik Ronne" <serse@diku.dk> wrote in message
> news:1f14gvw.30tiw11768kwnN%serse@diku.dk...
> > Du skal passe på med dine ordvalg. Det der i relationsdatabaseteorien
> > kaldes en /relation/, det matematiske begreb for en mængde af tupler, er
> > det der i de fleste databaser kaldes en tabel.
> >
> > Jeg bliver bare forvirret.
>
> Det er jeg også: "det der i relationsdatabaseteorien kaldes en
> /relation/...er det der i de fleste databaser kaldes en tabel"???

Ja. En fuldstændig eksaks beskrivelse.

> Jeg taler også om relationelle databaser, og i det sammenhæng er disse
> tabeller relationer.

Hvis vi ikke taler om relationelle databaser, giver det slet ikke mening
at tale om relationer.

> At jeg skrev "relation" var også med vilje idet jeg
> ville understrage at der er tale om en "relationship"-sammenhæng
> (mange-til-mange).

Nu blander du to teorisæt sammen: Databaseteori og E-R modellering. En
relation er to vidt forskellige ting i de to sammenhænge. I
databaseteori findes der kun relationer, og de implementeres som
tabeller, sædvanligvis som en tabel pr. relation. I E-R modellering
findes der såvel entiteter som relationer, og begge dele implementeres
som tabeller, men her er der ikke nødvendigvis en en-til-en sammenhæng.


--
Kristian Damm Jensen | Feed the hungry. Go to
kristian-damm.jensen@cgey.dk | http://www.thehungersite.com
Two wrongs doesn't make a right, but three lefts does.

---

"Kristian Damm Jensen" <kristian-damm.jensenRE@MOVEcgey.com> wrote in
message news:3BC6CB39.86E20671@MOVEcgey.com...
> Stranger wrote:

> Hvis vi ikke taler om relationelle databaser, giver det slet ikke mening
> at tale om relationer.

Ja, hvad ellers?

> Nu blander du to teorisæt sammen: Databaseteori og E-R modellering.

Som sagt det var med vilje at jeg skrev "relation" for at understrege
tabellens reele funktion.

> En relation er to vidt forskellige ting i de to sammenhænge. I
> databaseteori findes der kun relationer, og de implementeres som
> tabeller, sædvanligvis som en tabel pr. relation. I E-R modellering
> findes der såvel entiteter som relationer, og begge dele implementeres
> som tabeller, men her er der ikke nødvendigvis en en-til-en sammenhæng.

Jeg er da klar over at det ikke nødvendigvis er en-til-en eller
en-til-mange, eller mange-til-mange, men, igen, ved at nævne at der er tale
om en mange-til-mange relation så siger jeg samtidigt noget om dets indhold
og funktion. Og selvfølgelig er det en tabel i denne sammenhæng (hvad
ellers???).
Og i øvrigt, det er rigtigt at entiteter som regel implementeres som
tabeller, men det gælder ikke (altid) relationer. Relationer i ER beskriver
sammenhænge, og om disse sammenhænge implementeres som separate tabeller
(som f.eks. i mit tilfælde) eller via fremmede nøgler er det for ER's
vedkommende underordnet.

Sjovt du nævner en en-til-en sammenhæng (selvom jeg sagde mange-til-mange) i
forbindelse med tabeller, selvom disse som regel ikke "implementeres" som
separate tabeller. Det modsate gælder en mange-til-mange relation.


Dejan

> Kristian Damm Jensen | Feed the hungry. Go to
> kristian-damm.jensen@cgey.dk | http://www.thehungersite.com
> Two wrongs doesn't make a right, but three lefts does.
>
>

---

Stranger wrote:
>
<snip>

> Jeg er da klar over at det ikke nødvendigvis er en-til-en eller
> en-til-mange, eller mange-til-mange, men, igen, ved at nævne at der er tale
> om en mange-til-mange relation så siger jeg samtidigt noget om dets indhold
> og funktion. Og selvfølgelig er det en tabel i denne sammenhæng (hvad
> ellers???).
> Og i øvrigt, det er rigtigt at entiteter som regel implementeres som
> tabeller, men det gælder ikke (altid) relationer. Relationer i ER beskriver
> sammenhænge, og om disse sammenhænge implementeres som separate tabeller
> (som f.eks. i mit tilfælde) eller via fremmede nøgler er det for ER's
> vedkommende underordnet.
>
> Sjovt du nævner en en-til-en sammenhæng (selvom jeg sagde mange-til-mange) i
> forbindelse med tabeller, selvom disse som regel ikke "implementeres" som
> separate tabeller. Det modsate gælder en mange-til-mange relation.

Imponerende som vi kan tale forbi hinanden. Ovenstående giver mig i al
fald det helt klare indtryk, at du ikke har forstået, hvad jeg skrev.
Hvilket bare er endnu en grund til at man skal passe på med at blande
terminologierne sammen. Hvilket var, hvad Per Rønne skrev, og jeg
støttede ham i.

For min part: EOD.


--
Kristian Damm Jensen | Feed the hungry. Go to
kristian-damm.jensen@cgey.dk | http://www.thehungersite.com
Two wrongs doesn't make a right, but three lefts does.

---

Stranger wrote:
>
> Hej, jeg skal til at lave en DB (oracle). Meningen er at man skal kunne søge
> i DBen ved brug af stikord. F.eks:
>
> biler
>
> artnr navn beskkrivelse
> stikord
> -----------------------------------------------------------------------
> 1 mercedes et eller andet bil,
> mercedes, disel
> 2 volvo et eller andet bil,
> volvo, benzin
>
> Meningen er når brugeren f.eks. søger efter "bil" så kommer begge tupler
> med. Hvis brugeren søger "bil, disel", så får han art. nr. 1 tilbage.
> Endvidere skal det være muligt at opdatere "stikord" sålades at brugeren kan
> slette og/eller tilføje nogle nye stikord.
> Jeg har overvejet at oprette en tabel "stikord" (og relation "rel"):
>
> stikord:
>
> sid ord
> ----------------
> 1 bil
> 2 disel
> 3 mercdes
> 4 volvo
> 5 benzin
>
> rel:
>
> artnr sid
> ------------------
> 1 1
> 1 2
> 1 3
> 2 1
> 2 4
> 2 5
>
> og "biler" har følgende tupler: artnr, navn, beskrivelse.
>
> og så kan jeg søge : SELECT artnr,navn FROM biler, stikord, rel WHERE
> ord=mercedes AND stikord.sid=rel.sid AND rel.artnr = biler.artnr:
>
> Og det ser vist fint ud, men findes der en anden mulighed? Jeg får jo en
> meget stor relation "rel".

Ja. Er det et problem? Og i givet fald: Hvorfor?

> Skal reglen om atomiske værdier altid overholdes,
> og hvis ikke,

Ikke nødvendigvis. Der kan være mange gode grunde til ikke at overholde
den, men man bør overveje sine grunde grundigt inden man bryder med så
basale principper for datamodellering. Talrige er de tilfælde, hvor
fortvivlede mennesker har søgt hjælp i denne og tilsvarende grupper for
at få søgninger til at fungere, hvor det basale problem var at man havde
overtrådt grundlæggende principper.

> hvordan kan man have "stikord" i tabel "biler", men hvor der
> samtidigt er muligt at søge og opdatere disse værdier?

Du kan sagtens implementere en tabel som den du har beskrevet i starten
af dit indlæg. I så fald vil du blive nødt til at bruge
strengmanipulation til at foretage søgninger og opdateringer. Ikke nogen
enkel opgave, men det kan lade sig gøre.

Prisen er, at du forkaster alle de fordele, der er ved at have en
effektiv databasen.

Hvad er gevinsten?

--
Kristian Damm Jensen | Feed the hungry. Go to
kristian-damm.jensen@cgey.dk | http://www.thehungersite.com
Two wrongs doesn't make a right, but three lefts does.

---

"Kristian Damm Jensen" <kristian-damm.jensenRE@MOVEcgey.com> wrote in
message news:3BC6CDA2.3171E253@MOVEcgey.com...
> Stranger wrote:

> Ja. Er det et problem? Og i givet fald: Hvorfor?

I en forholdsvis lille database er "normaliseringen" tit (efter min mening)
unødvendig. Ved at skabe flere "tabeller" gør arbejdet mere kompliceret og
man opnår ikke nogle bemærkelsesværdige forbedringer (hastighed). Om man bør
normalisere afhænger efter min mening af flere faktorer, først og fremmest
af databasens størrelse. Normaliseringen, og hermed et forsøg på at ungå
redundans er efter min mening arv fra fortiden da man havde forholdsvis
langsome systemer.

> Ikke nødvendigvis. Der kan være mange gode grunde til ikke at overholde
> den, men man bør overveje sine grunde grundigt inden man bryder med så
> basale principper for datamodellering. Talrige er de tilfælde, hvor
> fortvivlede mennesker har søgt hjælp i denne og tilsvarende grupper for
> at få søgninger til at fungere, hvor det basale problem var at man havde
> overtrådt grundlæggende principper.

Det er det jeg gør nu: overvejer og søger nogle gode råd.

> Du kan sagtens implementere en tabel som den du har beskrevet i starten
> af dit indlæg. I så fald vil du blive nødt til at bruge
> strengmanipulation til at foretage søgninger og opdateringer. Ikke nogen
> enkel opgave, men det kan lade sig gøre.

Det er også det jeg gerne vil vide

> Prisen er, at du forkaster alle de fordele, der er ved at have en
> effektiv databasen.
>
> Hvad er gevinsten?

Som jeg skrev ovenfor: en lille database har nødvendigvis ikke brug for de
"stramme" regler. Jo, man ungår gentagelser og gør søgningen lidt hurtigere,
men i forhold til alt det forarbejde, samt de efterfølgende hensyn der skal
tages (f.eks. hvis man laver en database og et Java-program som skal tale
med databasen. Programmør vil i dette tilfælde bruge mere tid på opgaven end
hvis man f.eks. havde kun een tabel, dvs. ikke nogen join, ikke
flerestedsopdateringer, ikke nogen hensyn til integriteten (delete on casade
f.eks.) osv.)

mvh Dejan


> Kristian Damm Jensen | Feed the hungry. Go to
> kristian-damm.jensen@cgey.dk | http://www.thehungersite.com
> Two wrongs doesn't make a right, but three lefts does.
>
>

---

"Dejan" <stranger@tdcspace.dk> writes:

> [ ... ] Normaliseringen, og hermed et forsøg på at ungå redundans er
> efter min mening arv fra fortiden da man havde forholdsvis langsome
> systemer.

Den har vel lige så meget til formål at sikre at de data man har i sin
database er konsistente.

Hvis man har redundant information liggende skal man også opdatere det
flere steder når der sker ændringer.

--
Jacob - www.bunk.cc
Don't mind him; politicians always sound like that.

---

"Jacob Bunk Nielsen" <spam@bunk.cc> wrote in message
news:m3lmifidxl.fsf@paven.bunk.cc...
> "Dejan" <stranger@tdcspace.dk> writes:
>
> > [ ... ] Normaliseringen, og hermed et forsøg på at ungå redundans er
> > efter min mening arv fra fortiden da man havde forholdsvis langsome
> > systemer.
>
> Den har vel lige så meget til formål at sikre at de data man har i sin
> database er konsistente.
>
> Hvis man har redundant information liggende skal man også opdatere det
> flere steder når der sker ændringer.
>
Og?
Hvis begrundelsen holder, så er det vel "bare" at fatte kodeblokken og
implementere de forretningsregler der skal til?

Jeg har selv lavet bookingsystemer hvor alle datoer er pindet ud til den
mindste detalje
fx
PK, Dato, DagNavnLang, DagNavnKort, DagIMåned, DagIÅr, Uge, Måned,
MånedNavnLang, MånedNavnKort, Kvartal, År

Det gav en forøgelse på ca 20% i applikationen på svartider
Databasen var lavet i Access

Der er forskel på data der ændres konstant og mere statiske data

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hotmail.com> writes:

[ Normalisering ]

> > Den har vel lige så meget til formål at sikre at de data man har i sin
> > database er konsistente.
>
> Og?

Der er da ikke nogen grund til at gøre det mere besværligt for sig
selv end højst nødvendigt.

Hvad sker der den dag du har har redundant data i databasen og en
anden applikation skal manipulere dem, og nogen laver en fejl, så de
kun bliver opdateret et af stederne?

Hvad sker der fx når du har følgende tabel (skal læses med en font med
fast bredde):

Vareid | Lager | Antal | Adresse
-----------------------------------
1 | L1 | 4 | Lagervej 2
2 | L2 | 5 | Lagervej 9
3 | L1 | 7 | Lagervej 2

.... og L1 så flytter til Lagervej 3. Så skal du pludselig til at
opdatere rigtig mange felter samt være opmærksom på at du får adressen
opdateret over det hele.

> Jeg har selv lavet bookingsystemer hvor alle datoer er pindet ud til den
> mindste detalje
> fx
> PK, Dato, DagNavnLang, DagNavnKort, DagIMåned, DagIÅr, Uge, Måned,
> MånedNavnLang, MånedNavnKort, Kvartal, År

Den slags havde *jeg* nok valgt at lave anderledes.

> Det gav en forøgelse på ca 20% i applikationen på svartider

Skræmmende. Du må have brugt nogle langsomme dato-funktioner. Hvad var
din applikation kodet i?

> Databasen var lavet i Access

Jeg kender desværre intet til Access.

> Der er forskel på data der ændres konstant og mere statiske data

Hvordan?

--
Jacob - www.bunk.cc
You have been selected for a secret mission.

---

"Jacob Bunk Nielsen" <spam@bunk.cc> wrote in message
news:m3het3i32g.fsf@paven.bunk.cc...
> "Peter Lykkegaard" <polonline@hotmail.com> writes:
>
> [ Normalisering ]
>
> > > Den har vel lige så meget til formål at sikre at de data man har i sin
> > > database er konsistente.
> >
> > Og?
>
> Der er da ikke nogen grund til at gøre det mere besværligt for sig
> selv end højst nødvendigt.
>
> Hvad sker der den dag du har har redundant data i databasen og en
> anden applikation skal manipulere dem, og nogen laver en fejl, så de
> kun bliver opdateret et af stederne?
>
Man laver en 3-tier applikation så andre klienter kun kan gå igennem
forretningsreglerne/com interfaces
Fx a la Baan/SAP/Axapta

> Hvad sker der fx når du har følgende tabel (skal læses med en font med
> fast bredde):
>
> Vareid | Lager | Antal | Adresse
> -----------------------------------
> 1 | L1 | 4 | Lagervej 2
> 2 | L2 | 5 | Lagervej 9
> 3 | L1 | 7 | Lagervej 2
>
Den er for oplagt
Du kan evt overveje problemet med LagerPost og LagerSum (beregnede
redundante data fra LagerPost)
Eksemplet er taget fra Damgaard XAL

> > Jeg har selv lavet bookingsystemer hvor alle datoer er pindet ud til den
> > mindste detalje
> > fx
> > PK, Dato, DagNavnLang, DagNavnKort, DagIMåned, DagIÅr, Uge, Måned,
> > MånedNavnLang, MånedNavnKort, Kvartal, År
>
> Den slags havde *jeg* nok valgt at lave anderledes.
>
> > Det gav en forøgelse på ca 20% i applikationen på svartider
>
> Skræmmende. Du må have brugt nogle langsomme dato-funktioner. Hvad var
> din applikation kodet i?
>
De forskellige tests blev lavet i ren SQL
Problemet opstår når du fx laver pivoteringer udfra ugedag
Det var her den største gevinst kom ind i billedet

Men også beregning af navn på ugedag og måned gav nogle pæne forskelle
Generelt set

Men som sagt var det i Access
Jeg har siden haft held til lave andre beregninger på MSSQL/T-SQL der
fungerer ganske fornuftigt

> > Databasen var lavet i Access
>
> Jeg kender desværre intet til Access.
>
WinXX - Programmeringsprog er SQL og VBA (Visual Basic for applications)
Den er iøvrigt filbaseret (ISAM)

> > Der er forskel på data der ændres konstant og mere statiske data
>
> Hvordan?
>
Fx data der bliver ændret hver time vil give lidt problemer når man skal
opdatere flere steder'
jvf tidligere eksempel med LagerPost/LagerSum
Kontra data der bliver indsat og aldrig siden ændret fx mit dato eksempel

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hotmail.com> writes:

> > [ Normalisering ]
> >
> > Hvad sker der den dag du har har redundant data i databasen og en
> > anden applikation skal manipulere dem, og nogen laver en fejl, så de
> > kun bliver opdateret et af stederne?
>
> Man laver en 3-tier applikation så andre klienter kun kan gå igennem
> forretningsreglerne/com interfaces

Det er selvfølgelig en mulighed, men er det ikke bare at gør det
besværligt for sig selv?

> Fx a la Baan/SAP/Axapta

Det kender jeg desværre ikke.

> > Hvad sker der fx når du har følgende tabel (skal læses med en font med
> > fast bredde):
> >
> > Vareid | Lager | Antal | Adresse
> > -----------------------------------
> > 1 | L1 | 4 | Lagervej 2
> > 2 | L2 | 5 | Lagervej 9
> > 3 | L1 | 7 | Lagervej 2
>
> Den er for oplagt

Ja, det var da derfor jeg fandt på eksemplet

> Du kan evt overveje problemet med LagerPost og LagerSum (beregnede
> redundante data fra LagerPost)

Jeg ville da være meget ked af at skulle holde styr på både en sum og
et antal poster, hvor summen bare er summen (tada!) af posterne. Det
kan da kun give anledning til at nogen laver rod en dag.

> Eksemplet er taget fra Damgaard XAL

Øhhh, jeg troede det var taget fra min hoved. Jeg kender slet ikke XAL.

> Men også beregning af navn på ugedag og måned gav nogle pæne forskelle
> Generelt set

Skræmmende. Det er jo ganske simple beregninger, som mange (de
fleste?) programmeringssprog har biblioteker til at regne ud.

> Men som sagt var det i Access
> Jeg har siden haft held til lave andre beregninger på MSSQL/T-SQL der
> fungerer ganske fornuftigt

Lignende beregninger? Det vil sige at det bare var Access der stank?

> > Jeg kender desværre intet til Access.
>
> WinXX - Programmeringsprog er SQL og VBA (Visual Basic for applications)

Ja, jeg var godt klar over det var til Windows, men der slap min
viden også op. Nok netop fordi det er til Windows

> > > Der er forskel på data der ændres konstant og mere statiske data
> >
> > Hvordan?
>
> Fx data der bliver ændret hver time vil give lidt problemer når man skal
> opdatere flere steder'
> jvf tidligere eksempel med LagerPost/LagerSum
> Kontra data der bliver indsat og aldrig siden ændret fx mit dato eksempel

Jeg tror stadig ikke jeg har forstået det.

Er det rigtigt når jeg forstår dig som at det OK at gemme redundant
data når bare det ikke er noget man manipulerer så tit?

Man skal jo stadig have det ind i sin database, og helst så det man
putter i den er konsistent. Så er det vel uden betydning om
ændringsfrekvensen er høj eller ej, hvis man først har indført en
unødig kompleksitet og deraf følgende fare for fejl når data
opdateres/indsættes.

--
Jacob - www.bunk.cc
In the war of wits, he's unarmed.

---

"Jacob Bunk Nielsen" <spam@bunk.cc> wrote in message
news:m3wv1yba25.fsf@paven.bunk.cc...
> "Peter Lykkegaard" <polonline@hotmail.com> writes:
>
> > > [ Normalisering ]
> > >
> > > Hvad sker der den dag du har har redundant data i databasen og en
> > > anden applikation skal manipulere dem, og nogen laver en fejl, så de
> > > kun bliver opdateret et af stederne?
> >
> > Man laver en 3-tier applikation så andre klienter kun kan gå igennem
> > forretningsreglerne/com interfaces
>
> Det er selvfølgelig en mulighed, men er det ikke bare at gør det
> besværligt for sig selv?
>
Man laver 3-tier modellen for at gøre vedligeholdesen mere enkel
Ændrer/Udvider man forretningsmodellen skal det kun implementeres ét sted
(event 2 hvis det også kræver ændringer i databasemodellen)

I første omgang er det besværligt (meget) - men på langt sigt er det (burde
være) peace of cake

> > Du kan evt overveje problemet med LagerPost og LagerSum (beregnede
> > redundante data fra LagerPost)
>
> Jeg ville da være meget ked af at skulle holde styr på både en sum og
> et antal poster, hvor summen bare er summen (tada!) af posterne. Det
> kan da kun give anledning til at nogen laver rod en dag.

Typisk er de beregninger så komplekse at det ikke kan svare sig
Lagerbeholdningen skal jo beregnes udfra _alle_ bevægelser på lageret siden
opstart af applikationen
Fx mellem 100 og 500 bevægelser * 360 dage * antal år * antal varenumre
Varenumre dog skifte over tid

Man kan så vælge at flytte lagerbevægelser fra foregående regnskabsår over i
en historik database - men det giver jo andre problemer at slås med

> > Jeg har siden haft held til lave andre beregninger på MSSQL/T-SQL der
> > fungerer ganske fornuftigt
>
> Lignende beregninger? Det vil sige at det bare var Access der stank?
>
Ja og nej - jeg skrev _andre_ beregninger
Som sagt har jeg ikke haft lejlighed til at efterprøve problemstillingen på
MSSQL

Access "stinker" ikke (imho) - man skal bare kende dens begrænsninger
Man kører jo heller på cykel fra København til Aalborg hvis man skal på
kundebesøg

> > > > Der er forskel på data der ændres konstant og mere statiske data
> > >
> > > Hvordan?
> >
> > Fx data der bliver ændret hver time vil give lidt problemer når man skal
> > opdatere flere steder'
> > jvf tidligere eksempel med LagerPost/LagerSum
> > Kontra data der bliver indsat og aldrig siden ændret fx mit dato
eksempel
>
> Jeg tror stadig ikke jeg har forstået det.
>
> Er det rigtigt når jeg forstår dig som at det OK at gemme redundant
> data når bare det ikke er noget man manipulerer så tit?
>
Der er forskel på den logiske fuldt normaliserede datamodel og så den
aktuelle fysiske implementering
Man skal have en god begrundelse for at afvige fra den logiske model og gøre
sig klart hvad man har gang i
Der er mange forskellige parametre der kan gøre at man bliver "nødt" til at
have redundante data
Man bør ikke (og skal ikke) holde fast i den logiske model for enhver pris -
imho

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hot.mail.com> writes:

> > > > [ Normalisering ]
> >
> Man laver 3-tier modellen for at gøre vedligeholdesen mere enkel
> Ændrer/Udvider man forretningsmodellen skal det kun implementeres ét sted
> (event 2 hvis det også kræver ændringer i databasemodellen)

Nu er jeg desværre ikke nogen databasehaj (endnu), så har du et link
til noget om 3-tier modellen. Det er ikke umiddelbart noget der siger
mig så meget.

> I første omgang er det besværligt (meget) - men på langt sigt er det (burde
> være) peace of cake

Sådan er det jo ofte med ting der bliver lavet fornuftigt. Det tager
en del tid at lave det hele fornuftigt og gennemtænkt. Gevinsten er at
det bliver lettere at vedligeholde/udvide.

> > Jeg ville da være meget ked af at skulle holde styr på både en sum og
> > et antal poster, hvor summen bare er summen (tada!) af posterne. Det
> > kan da kun give anledning til at nogen laver rod en dag.
>
> Typisk er de beregninger så komplekse at det ikke kan svare sig
> Lagerbeholdningen skal jo beregnes udfra _alle_ bevægelser på lageret siden
> opstart af applikationen
> Fx mellem 100 og 500 bevægelser * 360 dage * antal år * antal varenumre
> Varenumre dog skifte over tid

Jeg tror jeg misforstod dig i første omgang. På den måde giver det
mening at holde styr på en sum ved siden af.

Jeg forstod dig som at du har et antal lagre, og de hver har et antal
af en vare liggende, som man så bare opdaterer når man får varer hjem
eller sælger noget.

Det er nok foranlediget af mit oprindelige eksempel.

> Man kan så vælge at flytte lagerbevægelser fra foregående regnskabsår over i
> en historik database - men det giver jo andre problemer at slås med

Ja, det kan også let blive noget rod.

> > > Jeg har siden haft held til lave andre beregninger på MSSQL/T-SQL der
> > > fungerer ganske fornuftigt
> >
> > Lignende beregninger? Det vil sige at det bare var Access der stank?
> >
> Ja og nej - jeg skrev _andre_ beregninger

Det gjorde du også

> Access "stinker" ikke (imho) - man skal bare kende dens begrænsninger

OK, ganske som MySQL, som jeg har brugt en smule.

> Man kører jo heller på cykel fra København til Aalborg hvis man skal på
> kundebesøg

Nej, det gør man vist kun hvis man er fanatisk (og stadig ikke skal på
kundebesøg :)

> > Er det rigtigt når jeg forstår dig som at det OK at gemme redundant
> > data når bare det ikke er noget man manipulerer så tit?
> >
> Der er forskel på den logiske fuldt normaliserede datamodel og så den
> aktuelle fysiske implementering

Absolut.

> Man skal have en god begrundelse for at afvige fra den logiske model og gøre
> sig klart hvad man har gang i

Nemlig! For mig virkede det umiddelbart som om det var det du ikke
havde tænkt inden du skrev, som du gjorde. Så tror jeg at vi er tæt på
at være enige.

> Man bør ikke (og skal ikke) holde fast i den logiske model for enhver pris -
> imho

Jeg mener at man skal gøre en ret stor indsats for det. Men det er
vist også hvad jeg kan udlede at du er enig i.

--
Jacob - www.bunk.cc
If you have to hate, hate gently.

---

"Jacob Bunk Nielsen" <spam@bunk.cc> wrote in message
news:m34rozed0l.fsf@paven.bunk.cc...
> "Peter Lykkegaard" <polonline@hot.mail.com> writes:
>
> > > > > [ Normalisering ]
> > >
> > Man laver 3-tier modellen for at gøre vedligeholdesen mere enkel
> > Ændrer/Udvider man forretningsmodellen skal det kun implementeres ét
sted
> > (event 2 hvis det også kræver ændringer i databasemodellen)
>
> Nu er jeg desværre ikke nogen databasehaj (endnu), så har du et link
> til noget om 3-tier modellen. Det er ikke umiddelbart noget der siger
> mig så meget.
>
Kort fortalt
Database
Forretningsmodel
Præsentationslag

I databasen gemmer du dine data - (obvious
I forretningsmodellen bestemmer du dit dataflow/regler mv
I præsentationslaget - ja det er lig med brugerfjæset

Nogle steder at starte
http://www.google.com/search?sourceid=navclient&q=3%2Dtier
http://www.cit.teknologisk.dk/brugergrupper/corbaerfa/biblioteket/matmoder/-
dec99/-diskuss.asp

mvh/Peter Lykkegaard

---

Dejan wrote:
>
> "Kristian Damm Jensen" <kristian-damm.jensenRE@MOVEcgey.com> wrote in
> message news:3BC6CDA2.3171E253@MOVEcgey.com...
> > Stranger wrote:
>
> > Ja. Er det et problem? Og i givet fald: Hvorfor?
>
> I en forholdsvis lille database er "normaliseringen" tit (efter min mening)
> unødvendig. Ved at skabe flere "tabeller" gør arbejdet mere kompliceret og
> man opnår ikke nogle bemærkelsesværdige forbedringer (hastighed). Om man bør
> normalisere afhænger efter min mening af flere faktorer, først og fremmest
> af databasens størrelse. Normaliseringen, og hermed et forsøg på at ungå
> redundans er efter min mening arv fra fortiden da man havde forholdsvis
> langsome systemer.

For det første (generelt): Normalisering er ikke et forsøg på op
køretidsoptimere. Det er ikke det, der er grunden til at man gør det,
hverken dengang eller nu. Man normaliserer for at undgå redundans og for
at føre vedligeholdelse nemmere.

For det andet: Jeg spurgte efter konkrete grunde til at det er et
problem. Ikke generelle.

Du spurgte om hjælp til et konkret problem, men for at kunne give dig
nogle råd, skal vi have nogle mere præcise informationer. ´

Altså igen: Hvorfor er det i dit konkrete tilfælde et problem, at du får
en meget stor relation, hvis du normaliserer?

<snip>

--
Kristian Damm Jensen | Feed the hungry. Go to
kristian-damm.jensen@cgey.dk | http://www.thehungersite.com
Two wrongs doesn't make a right, but three lefts does.

---

"Kristian Damm Jensen" <kristian-damm.jensenRE@MOVEcgey.com> wrote in
message news:3BCAD179.7F7D257E@MOVEcgey.com...
-snip-
> For det andet: Jeg spurgte efter konkrete grunde til at det er et
> problem. Ikke generelle.
>
> Du spurgte om hjælp til et konkret problem, men for at kunne give dig
> nogle råd, skal vi have nogle mere præcise informationer. ´
> Altså igen: Hvorfor er det i dit konkrete tilfælde et problem, at du får
> en meget stor relation, hvis du normaliserer?

Jeg tvivler meget på at du kan hjælpe nogen som helst når du på forhond
afviser alle andre meninger eller opfattelser.
Jeg har sagt hvorfor: fordi normaliseringen giver mere programmeringsarbejde
(hermed DB design), fra tanke, via selve normaliseringen, til
implementationen. Større arbejde= mere tid, tid = penge.
Men som du sagde:
For min part: EOD.

Tak for dit hjælp.

Dejan

> Kristian Damm Jensen | Feed the hungry. Go to
> kristian-damm.jensen@cgey.dk | http://www.thehungersite.com
> Two wrongs doesn't make a right, but three lefts does.
>

---

"Dejan" <stranger@tdcspace.dk> wrote in message
news:3bcb0d04$0$268$edfadb0f@dspool01.news.tele.dk...
>
> "Kristian Damm Jensen" <kristian-damm.jensenRE@MOVEcgey.com> wrote in
> message news:3BCAD179.7F7D257E@MOVEcgey.com...
> -snip-
> > For det andet: Jeg spurgte efter konkrete grunde til at det er et
> > problem. Ikke generelle.
> >
> > Du spurgte om hjælp til et konkret problem, men for at kunne give dig
> > nogle råd, skal vi have nogle mere præcise informationer. ´
> > Altså igen: Hvorfor er det i dit konkrete tilfælde et problem, at du får
> > en meget stor relation, hvis du normaliserer?
>
> Jeg tvivler meget på at du kan hjælpe nogen som helst når du på forhond
> afviser alle andre meninger eller opfattelser.
> Jeg har sagt hvorfor: fordi normaliseringen giver mere
> programmeringsarbejde (hermed DB design), fra tanke, via selve
normaliseringen, til
> implementationen. Større arbejde= mere tid, tid = penge.
>
Jeg er da endog meget glad for at jeg ikke er kunde i det firma...
"Bare smæk noget skod sammen i en fart det virker jo ved første øjekast..."

mvh/Peter Lykkegaard

---

Dejan <stranger@tdcspace.dk> wrote:

> Jeg har sagt hvorfor: fordi normaliseringen giver mere programmeringsarbejde
> (hermed DB design), fra tanke, via selve normaliseringen, til
> implementationen.

Det er nu ikke min erfaring.
--
Cand. scient. Per Erik Rønne <datalogi, engelsk>
Frederikssundsvej 308B, DK-2700 Brønshøj, DENMARK, EUROPEAN UNION
Tlf. + fax: +38 89 00 16, mobil +45 28 23 09 92.
Homepage http://www.diku.dk/students/xerxes

---

Dejan wrote:
>
> "Kristian Damm Jensen" <kristian-damm.jensenRE@MOVEcgey.com> wrote in
> message news:3BCAD179.7F7D257E@MOVEcgey.com...
> -snip-
> > For det andet: Jeg spurgte efter konkrete grunde til at det er et
> > problem. Ikke generelle.
> >
> > Du spurgte om hjælp til et konkret problem, men for at kunne give dig
> > nogle råd, skal vi have nogle mere præcise informationer. ´
> > Altså igen: Hvorfor er det i dit konkrete tilfælde et problem, at du får
> > en meget stor relation, hvis du normaliserer?
>
> Jeg tvivler meget på at du kan hjælpe nogen som helst når du på forhond
> afviser alle andre meninger eller opfattelser.

Jeg er da ked af, hvis du opfatter mine indlæg sådan. Jeg har tværtimod
tidligere givet udtryk for at jeg mener, der kan være gode grunde til
ikke at normalisere. I konkrete tilfælde. Med konkrete grunde. Hvor
fordele og ulemper er afvejet mod hinanden.

> Jeg har sagt hvorfor: fordi normaliseringen giver mere programmeringsarbejde
> (hermed DB design), fra tanke, via selve normaliseringen, til
> implementationen.

Jeg har derimod endnu til gode, at se et eksempel, hvor dette er
korrekt. Især, hvis man indregner efterfølgende vedligeholdelse.

På den anden side har jeg også tidligere givet et skøn over hvilke
komplikationer du kaster dig ud i, hvis du dropper kravet om atomiske
data (hvad du oprindelig luftede muligheden af).

> Større arbejde= mere tid, tid = penge.
> Men som du sagde:
> For min part: EOD.

Det sagde jeg i en anden del af tråden, hvor vi diskuterede terminologi
og teoretiske aspekter.

> Tak for dit hjælp.

Hvilken hjælp?

--
Kristian Damm Jensen | Feed the hungry. Go to
kristian-damm.jensen@cgey.dk | http://www.thehungersite.com
Two wrongs doesn't make a right, but three lefts does.