sslug-teknik team mailing list archive

[Bjørn Bille Højte <bjoern@xxxxxxxxxxxxx>]

On Tue, 19 Feb 2002, E. Sjørlund wrote:

> Det forekommer mig, at du blander design og bekvemmelighed sammen.
> Det at du har "forfattere" <--> "relationstabel" <--> "værker" er et
> designspørgsmål. Det kan ikke gøres bedre

Indrømmet, og i det originale design er det også måden det er gjort på.
Det er bare - i visse tilfælde - nemmere at gøre på denne måde. Jeg
indrømmer at det giver nogen redundans, men jeg ved altid hvor jeg skal
finde forfatterenheden. Det er også nemmere at retablere tabellen fra
ingenting, idet man blot ser på bogen og laver en ny forfatterenhed,
hvorefter alle bøgerne med den forfatterenhed er i luften igen (ja - det
er sket, lige før jeg lavede min første backup).

> Det, at du har eksempler på, at de samme x forfattere har tilknytning til
> flere værker, og derfor gerne ville kunne oprette en ny klump forfattere (de
> samme) med et andet værk er et bekvemmelighdes problem, som du ikke må lade
> forplumre dit design. Hvis det virkeligt sker så tit, så det er generende,
> så lave en tabel med forfattergrupper, og giv i dit program adgang til at
> vælge en klump af forfattere på en gang.

Og så forstod jeg - efter 4. gennemlæsning - hvad du skrev. Det undgik mig
lige til at starte med at det ikke var i visningen du ville henvise til
klump-tabellen men kun i oprettelsen af nye rækker.

Du har naturligvis ret. forfattergruppe tabellen har jeg jo. Nu er det
bare sådan, at en sådan tabel jo også skal vedligeholdes, og så kommer vi
tilbage til valideringen som var det der startede hele denne tråd.

Jeg vil nu se lidt på muligheden... Jeg regner ikke med at miste tabellen
igen.

Jeg har igennem de sidste par år oplevet en vis forskel mellem teori og
praksis. I teorien er databaser uden redundans en "God Ting". I praksis
kan det være ekstremt tyngende i hastighed. Man opretter så "bare lige" et
ekstra felt og indeks. Man har ganske vist redundante data og indeks, til
gengæld er hastigheden kommet op. Jeg forudser ikke at det bliver et
problem min lille bogdatabasen, men jeg har set andre databaser hvor det
har været det. Man kan altså ikke altid HELT skille design og
bekvemmelighed i implementation.

> Hvad angår brugen af isbn som key, er det den eneste fornuftige løsning.
> De bøger, der ikke har et isbn nummer, tildeler du blot et.

De bøger der ikke har et ISBN nummer har ikke et ISBN nummer. Hvis jeg
selv danner et, risikerer jeg at støde sammen med nogle allerede tildelte
numre. Det er dog ikke sandsynligt.

> 1. Du skal jo ikke senere kunne søge på det ikke eksisterende isbn nummer,
> men alene have en unik key på posten.

Det hænder rent faktisk at jeg trækker informationen om hvilke bøger der
IKKE har ISBN nummer ud.

> Det forkommer mig, at du gør dig unødige bekymringer på det punkt.

Ingen bekymringer. Jeg bruger ikke ISBN som indeks. Jeg bruger et unique
indekseret integer som databasen selv sørger for bliver talt op. Hvis der
ikke er ISBN på en bog, så er det bare endnu en information til databasen
(ingen information er også information).

> Det virker altså også lidt, som om du har en opfattelse af, at en databases
> design har noget som helst at gøre med, hvad man vil trække ud af den. Det
> har det ikke.

Som beskrevet tidligere, så har det - til en hvis grad - indflydelse på
databasens udseende. Ikke nødvendigvis det originale design, men absolut
på den måde databasen bliver implementeret på.

> Björn Lundins råd om tabel <--> relationstabel <--> tabel giver et nydeligt
> og robust design, som du altd kan få de ønskede oplysninger ud af. Samtidigt
> giver den dig den frihed, at du kan slette poster i begge tabeller med
> kaskadevis sletning i relartionstabellen, uden at det koster i den anden.

Det kommer jeg til senere, når jeg begynder at implementere sletninger.
Foreløbig er jeg - igen - igang med at indsætte. Jeg ser dog ingen
hindringer i kaskadevis sletning, heller ikke som databasen ser ud lige
nu.


Med venlig hilsen
Bjørn Bille Højte
bjoern@xxxxxxxxxxxxx