I mitt lille eksempel så lagrer jeg filmer, hver film skal ha informasjon om sjanger/kategori og en beskrivelse av filmen.

Eksempel:



Med tanke på at det finnes et gitt antall forskjellige sjangre, så tenker jeg at jeg har en egen tabell med sjangre å velge imellom, slik at jeg unngår å ha repetative data i film-tabellen. Jeg vet at en film kan ha flere sjangre, men i dette eksempelet så sier vi at en film kun kan ha én sjanger. Dette vil altså si at jeg må ha et one-to-many relationship, hvor one=filmer, og many=sjangre.

Dette blir seende slik ut:


Det som er problematisk, er at nå blir det litt bakvendt. Jeg vil jo definere kategorien som tilhører filmen når jeg oppretter en ny film, men nå er det slik at jeg først må definere filmen, så må jeg gå til kategori-tabellen og legge til filmen der etterpå. Dette virker ikke hensiktsmessig?


Dersom jeg gjør det motsatt som dette:


Da kan jeg spesifisere kategorien i foreign key feltet på hver film, men da blir det jo filmen som har many? Hva er det jeg har missforstått her? Databaser er skikkelig forvirrende

Det ER definitivt denne måten man gjør det på, og det er akkurat dette databaser er gode på - sammenlignet med å lagre ting i tekstfiler eller lignende.

Ut i fra måten du spør på, så virker det for meg som om du kanskje ikke har vært borti JOIN-statements i SQL før. Det man i praksis gjør når man har en felles kolonne i flere tabeller er at man skriver en JOIN-statement som sammenslår de aktuelle tabellene til én. Denne sammenslåingen gjøres kun "virtuelt" i selve spørringen, ikke "fysisk" i databasen.

Jeg kan hente ut alle venner i ett steg:
Som du sier så er dette kanskje et litt søkt eksempel, og derfor blir også spørringen vanvittig lang - men som du ser er det et helt tydelig mønster her. Finn kolonnen som er delt mellom to tabeller og gjør en JOIN på dem. Jeg bruker aliaser her for å korte ned navnet på tabellene, slik at man også tydeligere kan se hva som er hva (dette er det AS som gjør, men du kan også omgå selve nøkkelordet "AS" hvis du vil skrive det enda kortere).

I dette eksempelet bruker jeg en INNER JOIN, en av mange ulike typer joins. Jeg bruker dette her som referansedokument når jeg skriver JOIN-statements, det er en veldig hendig jukselapp:
https://blog.codinghorror.com/a-visu...-of-sql-joins/

En annen ting du bør se på er om databasen din støtter "foreign keys". Dette er en fiffig indeks-type som gjør at du tar slike felles-kolonner et steg videre, og knytter tabellene enda tettere sammen. Med foreign keys kan du gjøre databehandling på en mye enklere måte. Et eksempel er at du kan slette en film fra Filmer-tabellen, og en foreign key kan da automatisk slette alle rader fra andre tabeller som er knyttet til denne spesifikke filmen. Uten foreign keys måtte du ha gjort slettingen manuelt i alle tabeller som er påvirket.

Takk for svar Moff Jeg har brukt joins, men har trodd at jeg kanskje gjør ting feil med tanke på at det virker så uoptimalt ut, sikkert bare i hodet mitt Japp, jeg bruker MySQL, og har satt opp foreign keys med cascade on update/delete.

Takker og bukker

Det er klart at det kan vente til senere, men indekser kommer automatisk på primærnøkler og lager du en indeks for hver fremmednøkkel også er du ~80% på veien til en optimalisert database.

Hvis man har data fra flere flere forskjellige områder er det god praksis å lage et eget skjema for hvert område, da ville tabellene for eksempel kalles film.kategorier og film.filmer, mens en annen tabell kunne vært nettbutikk.kategorier e.l.

De to siste spm avhenger egentlig kun av preferanse - så lenge man er konsistent i navngivingen.

Jo. Skjemaer har ingen enorm innvirkning på hvordan ting fungerer. (Så vidt jeg vet. Dette kan godt variere kraftig fra ett db-system til et annet.)

Du vil *ikke* lagre tags kommaseparert i databasen, dette ødelegger normaliseringen og gjør både søk og endringer mye, mye mindre effektive. Tags på filmer vil definitivt være et mange-til-mange-forhold, og du trenger en "bindetabell" slik du nevner.