lagre data av ukjent antall, assosiasjons tabell?

[South_Bridge]

La oss si jeg hadde tenkt til å gjøre noe crazy som å lage en db som holder rede på innbyggere i en by, Oslo for eksempel. Jeg er ikke så skilled i db så første utkastet mitt på tabellen ville å ha sett noe slik ut

 

id INT,
name VARCHAR,
inhabitan1 VARCHAR,
inhabitan2 VARCHAR,
inhabitan3 VARCHAR,
inhabitan4 VARCHAR,
...

 

Men Oslo har flere hundre tusen innbyggere så den layouten er helt latterlig.

 

Så googler jeg litt og ser at noen nevner assosiasjonstabeller? Kan det løse problemet mitt? Hvordan implementerer jeg det?

Endret 5. mars 2010 av South_Bridge

[Ekko]

Lag en tabell med osversikt over innbyggere og byer enkeltvis

 

Tabell 1 - Byer

ById, Bynavn

 

Feks:

(1, Oslo)

(2, Bergen)

(3, Trondheim)

 

Tabell 2 - Inbyggere

(PersonID, Fornavn, Etternavn, Fodselsar, ByID)

 

Feks

(1, Jens, Stoltenberg, 1960, 1)

(2, Jenny, Skavland, 1982, 1)

(3, Kurt, Nilsen, 1978, 2)

(4, Åge, Aleksandersen, 1952, 3)

Endret 5. mars 2010 av Ekko

[JarlG]

Eg er absolutt ikkje særleg flink sjølv i database-språk, men eg ville gjort det slik på mi eiga mysql-server;

 

Tenkjer at dette systemet kan bli sote opp som ein vanleg tabell over registrerte brukarar.

 

CREATE TABLE innbyggere (
navn VARCHAR(30),
etternavn VARCHAR(30),
fødselsdato DATE NOT NULL
) DEFAULT CHARACTER SET utf8;

 

Her vil ein kunne sette inn personane under kvarandre i tabellen, med denne informasjonen. Du kan sjølvsagt legge til fleire kolonnar dersom du skal ha meir informasjon sote inn om kvar innbyggjar.

 

Kan vere lurt å google etter f.eks. eit registreringssystem, da det vil vere svært likt.

 

Håpar det var til hjelp.

[South_Bridge]

Lag en tabell med osversikt over innbyggere og byer enkeltvis

 

Tabell 1 - Byer

ById, Bynavn

 

Feks:

(1, Oslo)

(2, Bergen)

(3, Trondheim)

 

Tabell 2 - Inbyggere

(PersonID, Fornavn, Etternavn, Fodselsar, ByID)

 

Feks

(1, Jens, Stoltenberg, 1960, 1)

(2, Jenny, Skavland, 1982, 1)

(3, Kurt, Nilsen, 1978, 2)

(4, Åge, Aleksandersen, 1952, 3)

 

Vil ikke innbyggertabellen (inneholdene "1, Jens, Stoltenberg, 1960, 1") bli rimelig stor da den vil inneholde alle norges beboere da? Om man skal begynne å søke og slik i den. Feks hente ut alle beboere som bor i Farsund (en liten plass sammenlignet med resten av tabellen).

Endret 5. mars 2010 av South_Bridge

[TeisL]

Den vil kunne få like mange rader som det er i de tre byene til sammen. Så hvis det er noe slikt du skal lage, så ville jeg lest på database optimering og query optimering...

[Ekko]

Som teisl skriver så vil den bli stor ja, men det finnes ikke så mange måter å lagre 1 000 0000 navn uten at det tar litt plass.

 

Når det gjelder å finne innbyggere i Farsund finnes det måter å optimalisere på slik teisl skriver, feks indeksering.

Endret 5. mars 2010 av Ekko

[tomsi42]

Vil ikke innbyggertabellen (inneholdene "1, Jens, Stoltenberg, 1960, 1") bli rimelig stor da den vil inneholde alle norges beboere da? Om man skal begynne å søke og slik i den. Feks hente ut alle beboere som bor i Farsund (en liten plass sammenlignet med resten av tabellen).

Joda, og det er poenget. Ved hjelp av SQL så siler du ut de innbyggerene du vil ha tak i. Hvis Farsund er har ById lik 4, så får du kun de innbyggerene:

 

select personid, fornavn, etternavn, fodselar from innbyggere where byid = 4

Endret 5. mars 2010 av tomsi42

[endrebjo]

Dette forumet har over 15 millioner poster. Hver eneste post har blant annet én unik rad i en post-tabell som er felles for hele forumet. Altså en tabell med over 15 millioner rader. Så en database-tabell med 4 millioner innbyggere er "piece of cake" i databasesammenheng. Det er nettopp derfor vi bruker databaser. Databaser er vanvittig gode på å håndtere latterlig store datamengder, i motsetning til f.eks exel-tabeller.

 

 

[South_Bridge]

da er jo denne saken grei bare lurte på om det var faktisk det som var common pratice og fokusere mer på optimalisering.

[tomsi42]

da er jo denne saken grei bare lurte på om det var faktisk det som var common pratice og fokusere mer på optimalisering.

Når datamengdene blir store så bruker man indekser for å få litt fart på ting. Avhengig av database, så har man verktøy for å finne ut hvor effektive forskjellige søk (select) er. Mange databaser kan også fortelles (hints) om hvordan vi ønsker selecten skal utføres.