optimal opbygning af "stor" mysql database

Alle oplysninger som kan være redundante, dvs. fx. Bynavn skal være i en selvstændig database.

Bruger tabel:
Navn, Adresse, Postnr


PostBy tabel:
Postnr, Bynavn


Sådan ville jeg gøre det.

hvis det kun er en 2-3 stykker ud af 80 jeg kan gører det med ... er det så ikke næsten ligegyldigt ?

Man plejer at sige (Er det jeg har lært) at alt hvad der kan være i sin egen tabel som fx. Postnr hvor at flere jo har samme postnummer så skal man gøre det.

Når du har 80 felter pr. bruger er der noget der
tyder på at du skal oprette en række tabeller.
Normalisering til 3 normalform er et must hvis du vil
have en effektiv database. Der er en række krav der skal
være opfyldt men for at komme igang skal du undersøge om
alle felter er afhængige af primærnøglen, det er osse det
Leif er inde på.

Hvis tabellen ser sådan ud:

tblBruger
  BrugerID (PK)
  BrugerNavn
  BrugerAdresse
  BrugerPostnr
  BrugerBynavn

er bynavn ikke afhængig af BrugerID alene, bynavn er afhængig
af Postnr. Hvis postnummeret ændrer sig ændrer bynavnet sig osse.

Så derfor bør du lave det sådan:

tblBruger
  BrugerID (PK)
  BrugerNavn
  BrugerAdresse
  BrugerPostnr (FK)

tblBy
  Postnr (PK)
  Bynavn

Hvad der ellers skal ske af opdeling er ikke til at sige uden at
kende mere til de data du vil opbevare.

Med 500K brugere, bør du lave alle de optimeringer du overhovedet kan. Også selvom det umiddelbart ser ud til ikke at betyde så meget.

Mht postnummer, kan du evt gå skridtet videre end ffsoft beskriver.
Du kan lave tblBy sådan:

tblBy
  PostnrID (PK)
  Postnr
  Bynavn

tblBruger
  BrugerID
  PostnrID (FK)

Dette bør du gøre hvis du i højere grad læser postnummer oplysnigner end du opretter/editere brugernes postnummer oplysninger.

Desuden bør du grupere dine 80 brugerinfo efter hvordan de typisk skal hentes/editeres

Fx vil du typisk have brug for en selvstændig tabel med adresse oplysninger og måske en med login. Øvrige gruperinger afhænger af hvilke data det drejer sig om.

Princippet er at når en bruger skal logge ind, skal du kun bruge brugernavn, password og brugerid. Derfor placeres de i en tabel for sig selv.
Når du skal hente en adresse, skal du typisk kun bruge adressen og ikke fx personens interesser. Derfor placeres adresse og interesser i to adskilte tabeller.

/Bagge

Skal jeg dele den enkelte tabel op i så mange "kolonner" som muligt ?

eks.
hvis jeg har en oplysning hvad om hvad brugeren interessere sig for (bil, bad, dyr) er det så bedst det ligger i samme eller ?

Det er lidt svært at svare på ud fra de oplysninger du giver.

Een mulighed kunne være at lave 2 tabller

tblInteresser
  InteresseID (PK)
  InteresseNavn
  InteresseBeskrivelse

tblInteresseBrugere
  ID (PK)
  InteresseID (FK)
  BrugerID (FK)

tblBrugere
  BrugerID (PK)

Men om dette er optimalt, afhænger af hvad du skal have af data om brugernes interesser. Ovenstående er fint hvis du blot har "interessere brugeren sig for foldbold: ja/nej", men hvis hver bruger skal kunne skrive lidt om deres interesse, så vil det nok ikke være optimalt

Ved ikke helt hvad du havde tænkt dig ud fra dit spørgsmål, men hvis din tanke var at lave en kolonne med Bil, en kolonne med Dyr osv, så er det ihvertfald ikke en god ide.
Hver gang der kommer en ny interessetype til, skal du lave flere kolonner og ændre diverse sql.

/Bagge

Du skal prøve at tænke i enheder:

f. eks. Person, Interesse osv. Det er svært uden at vide hvad det er
du vil have af data.

Når du så har enhederne på plads skal du overveje relationerne imellem
enhederne, ud fra det kan du så lave tabellerne.

Database modellering som det hedder er en meget svær disciplin og
der er skrevet mange og tykke bøger om emnet, men det er meget nødvendigt
af få strukturen (tabeller og deres relationer) på plads.
Mange af de problemer der er med databaser skyldes en dårlig strukturering.

Det er meget svært at sige hvad du skal gøre, uden at vide hvad det er for
nogle data du vil gemme i databasen.