Relasjoner i mysql

[Noble]

Jeg har tre tabeller.

 

CREATE TABLE bedrift

(

bedrift_id int not null auto_increment,

navn varchar(255),

primary key (bedrift_id)

);

 

CREATE TABLE ansatt

(

ansatt_id int not null ,auto_increment,

navn varchar(255)

primary key (ansatt_id)

);

 

CREATE TABLE bedrift_ansatt

(

bedrift_id,

ansatt_id

);

 

 

Hvordan går jeg frem for å oppdatere tabellen bedrift_ansatt automatisk hver gang jeg legger noe til i tabellen ansatt og bedrift? Er dette noe som må gjøres ved en egen spørring HVER GANG, eller er det en enkel kommando som kan oppdatere dette automatisk?

[terjeelde]

Hvordan går jeg frem for å oppdatere tabellen bedrift_ansatt automatisk hver gang jeg legger noe til i tabellen ansatt og bedrift? Er dette noe som må gjøres ved en egen spørring HVER GANG, eller er det en enkel kommando som kan oppdatere dette automatisk?

 

Du må nok oppdatere bedrift_ansatt automatisk. Jeg mener, MySQL vil jo ha store problemer med å vite hvilke bedrift den ansatte skal være ansatt i, med mindre du forteller det via en spørring?

 

Men trenger du egentlig en slik mellomtabell? Hvis en person bare skal være ansatt i ett selskap, så kan du vel linke direkte fra den ansatte?

 

Er uansett forskjellig ansettelsesforhold om en person er ansatt i flere bedrifter, så sånnsett kan det være like greit å lage flere ansatt-rader om du skulle møte tilfeller hvor en er ansatt flere steder?

 

Kutter en tabell, enklere design, mindre jobb... Sounds good?

[Noble]

Dette var bare et eksempel. Jeg har flere tabeller og med flere rader.

 

Prøver å unngå å samle alle dataene i en tabell da det blir klatt med sletting, oppdatering og redudans av data.

 

Jeg har desverre ikke helt store erfaringene med sql, så dette er learn while doing

[quantum]

...

 

Hvordan går jeg frem for å oppdatere tabellen bedrift_ansatt automatisk hver gang jeg legger noe til i tabellen ansatt og bedrift? Er dette noe som må gjøres ved en egen spørring HVER GANG, eller er det en enkel kommando som kan oppdatere dette automatisk?

du kan definere en trigger, når det opprettes en rad i en tabell, kjører du insert i en annen. det er litt sært å gjøre det slik.

 

den vanlige måten å gjøre dette på er vel heller å definere fk-constraints slik at du ikke kan legge inn noe i bedrift_ansatt som ikke refererer til eksisterende rader i bedrift og ansatt. og så holder du orden på hva som skal hvor i koden din, og databasen sier ifra når du glemmer noe.

 

når du sletter kan du bruke cascade egenskapen til en fk for å få slettet tilknyttede data også.

 

http://en.wikipedia.org/wiki/Foreign_key_constraint

http://dev.mysql.com/doc/refman/5.1/en/inn...onstraints.html

[quantum]

Prøver å unngå å samle alle dataene i en tabell da det blir klatt med sletting, oppdatering og redudans av data.

meget god ide. det kalles normalisering og er viktig i databaseverdenen. redundans = større mulighet for feil (og da tenker jeg ifm. datamodell og ikke raid/clustering el. hvor redundans brukes for å *ikke* miste data ...)

 

i modellen din er bedrift og ansatt knyttet sammen i en mange-til-mange-relasjon (via bedrift_ansatt). det er nødvendig dersom en ansatt skal kunne være ansatt i flere bedrifter på en gang. hvis det ikke er nødvendig kan du droppe knyttetabellen og legge bedrift_id rett i ansatt-tabellen. du bruker sef fortsatt en fk-constraint.

 

http://en.wikipedia.org/wiki/Database_normalization

[Noble]

Takker. Det er altså ingen ekstra kommandoer jeg kjører for å linke disse databasene mot hverandre, sett bort fra JOIN?

 

Hva er forresten greia med JOIN? Du kan vel bare bruke WHERE x.y = y.x?

[quantum]

Takker. Det er altså ingen ekstra kommandoer jeg kjører for å linke disse databasene mot hverandre, sett bort fra JOIN?

 

Hva er forresten greia med JOIN? Du kan vel bare bruke WHERE x.y = y.x?

 

vet ikke hva du mener med å linke databaser, men hvis du mener å «linke tabeller» så «må» du altså definere fremmednøkler (foreign keys). dette er noe du gjør for å sikre dataintegriteten, personer skal ikke kunne være ansatt i ikke-eksisterende bedrift, bedrift skal ikke ha ikke-eksisterende ansatte.

 

greia med join er at du kan lage spørringer som henter data fra flere tabeller. det er fullt mulig å joine tabeller i en spørring uten å bruke nøkkelordet join, hvis det er dét du spør etter. du trenger heller ikke ha definert fremmednøkler for å joine. join av den typen du muligens refererer til med «where x.y = y.x» kalles inner join. hvis du f.eks. trenger en left join kan det være like greit å bruke syntax'en hvor du faktisk skriver «left join» så blir det litt mere lesbart.

 

Edit: mer om «greia med join» kan du lese f.eks. her: http://en.wikipedia.org/wiki/Join_(SQL) det kan være lurt å ta en liten pause i kodinga og lese deg litt opp på sql, så får du litt oversikt over hvordan det funker før du prøver å kode så mye. man kan lære mye når man koder, men det går dobbelt så fort om man leser litt ved siden av.

Endret 8. januar 2010 av quantum

[quantum]

...

Er uansett forskjellig ansettelsesforhold om en person er ansatt i flere bedrifter, så sånnsett kan det være like greit å lage flere ansatt-rader om du skulle møte tilfeller hvor en er ansatt flere steder?

 

Kutter en tabell, enklere design, mindre jobb... Sounds good?

nei, det er ikke så lurt. når man har mange-til-mange relasjoner bruker man en knyttetabell som det er gjort her.

[Noble]

Bruker man fremmednøkler i slike "knytetabeller"?

[quantum]

Bruker man fremmednøkler i slike "knytetabeller"?

 

Ja. Du ønsker ikke å ha rader i bedrift_ansatt som refererer til ikkeeksisterende data i bedrift eller ansatt. Med en fk_constraint forhindrer databasen deg fra å komme i en slik situasjon når du endrer, sletter eller legger inn data.

 

Og du bruker også fk-constraint når du ikke trenger knyttetabell. Dersom du hadde droppet bedrift_ansett tabellen, og bare hatt en bedrift_id i ansatt-tabellen (1:n-relasjon istedenfor n:n) ville du opprettet en fk-constraint på bedrift_id.

[quantum]

PS:

 

Når du oppretter fk-constraints kreves det indekser på feltene som er involvert. MySQL oppretter stort sett disse indeksene av seg selv når du spesifiserer fk-constraints. Dersom du vil ha en 1:1 fk-constraint oppnår du dette ved å sette indeksen på fremmednøkkelfeltet til unique.

 

I MySQL må du bruke InnoDb for å få til dette, ISAM mangler mange av de vanlige mekanismene for å opprettholde dataintegritet.