Ett table for text og ett for alt annet, fordeler?

[DevN]

(Litt vanskelig å komme opp med en god emnetittel, irriterende begrensning på 50 tegn.)

 

Ser at i phpBB2-forumet er det brukt ett table for emne og tekst, og ett for alt annet (tidspunkt, medlems-ID, osv.) for postene. Bringer dette noen fordeler? Eller kan man like gjerne bare ta alt i samme table?

[tasle]

Bruk av flere tabeller som henger sammen på et vis kalles for å normalisere. En normalisert database vil alltid være mye bedre enn en database der hummer og kanari er i kun en svær tabell. Bedre i den forstand at den blir mindre or raskere.

 

Eksempel, Kunder og salg:

Opprett en tabell for kundene (med kundenummer)

Opprett en annen tabell med kundenummer som fremmednøkkel, som inneholder hvert salg for kundene.

 

Fordeler:

Søk i kundetabellen etter en gitt kunde går raskere med bare kunder der, og ikke hver kunde oppført mange ganger med sine respektive salg. Denne tabellen blir mindre og dermed kjappere. Når kunden er funnet i kundetabellen, brukes kundenummer til å søke etter hvert salg i salgstabellen (som er mye mindre og kjappere enn om alt er i en tabell, fordi kundenavn, adresse, telefonnr mv. er lagret i kundetabellen og ikke i salgstabellen).

 

Lykke til med normalisering og logikk.

[olona]

Jeg kunne tenke meg en av to ting...

 

a) Kan det være et en til mange forhold mellom teksttabellen og "rest" tabellen? slik at du kan ha mange tekster til en post(?) Vet ikke hvorfor men...

 

b) noen databaser kan vel være trege når det gjelder søk i store tekst tabeller og dermed med å skille det ut på den måten, unngår du å bruke en tung teksttabell.

 

men disse tankene har du sikkert gjort selv også...si ifra hvis du finner ut noe mer spesifikt på denne her...

[tasle]

Ved normalisering er det kun 3 mulige relasjoner:

1) En-til-en (1:1)

2) En-til-mange (1:m)

3) Mange-til-mange (m:m)

 

En m:m relasjon kan ikke brukes i praksis fordi det ikke er mulig å entydig definere identifikatoren i noen av de to tabellene. Eksempel: To forskjellige personer har samme personnummer.

Dette løser man med å splitte opp en m:m relasjon (to tabeller) til 3 tabeller og får dermed to 1:m relasjoner.

 

Spørsmålet ditt har du i grunnen funnet svar på selv, en 1:m er helt OK, du kan godt ha mange tekster til en hovedpost. Eksempel "En bok har mange kapitler", eller

En CD tittel har mange låter

I det sistnevnte tilfellet (som kanskje er det mest praktiske av disse to) har man da to tabeller:

 

Tabell 1:

CD-Nr (som ID)

Tittel

Artist

Utgitt dato

Sjanger

 

Tabell 2:

CD-Nr (ID)

Navn på låten

Varighet av låten

 

Disse to tabellene knyttes sammen som en relasjon vha. CD-nr. som en 1:m relasjon (det er derfor det kalles for en relasjonsdatabase). Prinsippet brukes stort sett for alle praktiske formål når man lagrer data. Unntaksvis er små og særdeles enkle tabeller der antall poster aldri blir særlig stort (10-20-30 poster), da er liksom jobben med å normalisere større enn gevinsten.

 

Poenget med normalisering er å unngå "dobbeltlagring" av data. I eksemplet over ville man fått repeterende lagring av Tittel, Artist, Utgitt dato, Sjanger om man velger å bruke kun en tabell, fordi disse feltene måtte repeteres for hver enkelt låt i CD-tabellen om man hadde kun en tabell.

 

Begge tabellene er naturligvis indeksert. Det betyr at de er alfabetisk sortert etter CD-nr. I praksis brukes balanserte, binære trær som en svært hurtig mekanisme ved lagring og søking.

Eksempel: Hvis alle personer (ca. 9 milliarder) på kloden hadde hvert sitt unike personnummer, ville man bare trenge 33 søk maksimalt i tabellen for å finne data om en gitt person på kloden. Og det er jo en særdeles effektiv lagrings- og gjenfinningsmetode.

 

(Antall søk maksimalt = logaritmen til antall poster delt på logaritmen til 2, avrundet opp til nærmeste heltall)

 

Det samme gjelder for tekstene dine, med en normalisert database som bruker indeksering, går det veldig fort å finne frem til akkurat den teksten du er ute etter.

 

Access har slått sammen tabeller og indekser i en datafil, mens andre databasesystemer opererer med separate datafiler og hver sine tilhørende indeksfiler. Filendelsene i disse er gjerne *.DAT og *.IND eller *.INX eller tilsvarende.

 

Konklusjonen er at du ikke trenger å være redd for store datamengder hvor tabellene dine er normalisert, og indeksert.

[olona]

Bra forklaring på normalisering tasle! Takk.

 

Men spørsmålet til DevN gjenstår å bli besvart. (no offense)

 

Jeg mener, tviler jo sterkt på at gutta (og evnt jentene) som utviklet phpBB2 ikke vet hva normalisering er, og at de dermed har hatt en god grunn for å skille tabellen på den måten.

 

O.

[tasle]

De har nok det gjort etter oppskrifta med phpBB2, og normalisert som bare det...

Tabellen "Medlemmer" har flere oppføringer i tabellen "Tekster (innlegg)" for hvert medlem, så har de funnet ut at det er greitt å ha en kjapp tilgang til andre ting i andre separate tabeller, gjerne for statistiske formål eller andre ting. Felles er 1-til-mange mellom enten alle, eller de fleste av tabellene.

 

I tillegg har de nok helt sikkert en separat tabell for alle diskusjonsgrupper og Topics der en topic kan ha flere innlegg (en Diskusjonsgruppe kan være Hardware, Overklokking, Spill, Programmering osv), og en relasjon der hver Diskusjonsgruppe er en-til-mange mot undergrupper slik som her med databasegruppe, forskjellige programmeringsgrupper o.l.

 

Så til ditt første innlegg igjen, som jeg har nevnt tidligere, tabellene blir mindre og kjappere å søke i. Normalisering (mindre tabeller, kjappere respons) er deres gode grunn for å gjøre det slik. De har gått veien om 1. normalform, 2. normalform,... og helt til Boyes-Codd's normalform, mest sannsynlig. Slike diskusjonsfora kan fort bli temmelig svære med mange innlegg, og om alt var samlet i en tabell ville det tatt"evigheter" for å finne frem til et enkelt innlegg. Og det hele ville gitt en enorm datafil (tabell).

 

Så får du bare ha meg unnskyldt at jeg har blandet inn andre ting, men det er gjort for forhåpentligvis å lette forståelsen av en slik datamodell.

[DevN]

Glemte nesten av denne tråden, gitt.

 

Tror jeg har fått svarene jeg trenger på spørsmålet.

Skal normalisere som bare det nå.

 

Om jeg skulle sette opp en database for et nyhetssystem, er det altså en god ide å bruke tre tabeller?

1. Tittel, tid/dato, forfatter, osv.

2. Kort versjon av artikkelen.

3. Den hele og fulle versjonen av artikkelen.

 

Er det forresten en grense for hvor mye data en TEXT-enhet kan lagre? Hva skjer om grensen overstiges i så fall?

[tasle]

Ad 1)

Her bør du bruke Forfattere (med forfatter-ID, og andre faste data for hver hver forfatter) som entitet. (En forfatter -> har mange artikler). Tittel og tid hører til en artikkel, og da bør du ha en annen entitet (tabell) for Artikler, med attributter (datafelt) som gjelder for hver artikkel, inkludert tittel og tid.

 

Ad 2)

En ingress kan være greit å ha med i en egen entitet (tabell) for Ingresser. Ikke glem nøkkel (ID) for ingressene og artiklene i Artikler. En slik Identifikator behøver ikke være numerisk, den kan du konstruere etter behov. Eksempelvis en sammensatt nøkkel bestående av ForfatterID+Dato+Artikkelnr.

 

Ad 3)

Her spør du også om størrelser (kapasitet) for et tekstfelt. Jeg aner ikke hvilket databasesystem du har i tankene, men de fleste databasesystemer har mulighet for såkalte BLOB-felt (Binary Large Objects) som vanligvis benyttes til eksempelvis bilder og andre attributter som har en stor størrelse. Sjekk med manualen for det datasystemet hva størrelsen av et tekstfelt kan være...

 

Relasjonene mellom Forfattere og Ingresser blir 1:m. Mellom Forfattere og Artikler blir også 1:m, og mellom Ingresser og artikler blir 1:1. I tillegg mellom Forfattere og Ingresser 1:m.

 

Lykke til !

[DevN]

Ok, takk for hjelpa så langt. Har helt klart lært noen nyttige triks nå.