Indekser på flere felter

[mysjkin]

Hvordan bør man indeksere tabellen som brukes til å realisere en mange - til - mange kobling? Som eksempel, en musikkdatabase, hvert band har mange sanger, hver sang kan ha vært framført av mange band og vi får

 

create table band (
 id serial primary key,
 name char(255)
);

create table song(
 id serial primary key,
 name char(255)
);

create table bandsong(
  bandid bigint references band(id),
  songid bigint references song(id)
);

create unique index bandsong_idx on bandsong(bandid,songid);

 

Vil denne indexen (som hovedsaklig blir opprettet for å forhindre dobbelregistreringer) bli brukt når jeg søker bare på bandid i denne tabellen? Vil det være en fordel å også opprette separate indekser på bandid og songid, eventuelt når jeg har bandsong_idx. bør jeg også ha en index songband_idx som indekserer de samme feltene men i motsatt rekkefølge?

 

(Betraktninger om antallet sanger og band er uinteressante, jeg driver med andre databaser, men satt opp dette som et eksempel)

 

M.

[olona]

Nå kjenner jeg primært oracle.

 

Det korte svaret her er prøv. :-)

 

Det litt lenger svaret er at det dersom du bruker bandid og songid mye ville jeg absolutt laget en indeks hver på disse feltene.

 

Spørsmålet om indeks i motsatt rekkefølge vet jeg ikke svaret på. Visste ikke at det var mulig jeg å endre rekkefølgen på en indeks.

[PerB]

Hvordan bør man indeksere tabellen som brukes til å realisere en mange - til - mange kobling? Som eksempel, en musikkdatabase, hvert band har mange sanger, hver sang kan ha vært framført av mange band og vi får

[

5989826[/snapback]

Dette blir vel typisk mange til mange? Ofte må dette kobles via en/flere hjelptabell(er) slik at du for flere sett av en til mange/mange til en.

[ofredstie]

Hvordan bør man indeksere tabellen som brukes til å realisere en mange - til - mange kobling? Som eksempel, en musikkdatabase, hvert band har mange sanger, hver sang kan ha vært framført av mange band og vi får

 

 

 

Vil denne indexen (som hovedsaklig blir opprettet for å forhindre dobbelregistreringer) bli brukt når jeg søker bare på bandid i denne tabellen? Vil det være en fordel å også opprette separate indekser på bandid og songid, eventuelt når jeg har bandsong_idx. bør jeg også ha en index songband_idx som indekserer de samme feltene men i motsatt rekkefølge?

 

(Betraktninger om antallet sanger og band er uinteressante, jeg driver med andre databaser, men satt opp dette som et eksempel)

 

M.

5989826[/snapback]

 

Vet ikke hvilken database du bruker, men ser ut som PostgreSQL.. vil anbefale deg aa legge inn denne koden (modifisert din kode litt):

 

CREATE TABLE band (
 band_id SERIAL NOT NULL,
 name VARCHAR(30),
 --
 CONSTRAINT BAND_PK PRIMARY KEY (band_id)
);

CREATE TABLE song (
 sond_id SERIAL NOT NULL,
 name VARCHAR(30),
 --
 CONSTRAINT SONG_PK PRIMARY KEY (song_id)
);

CREATE TABLE bandsong (
  band_id BIGINT NOT NULL,
  song_id BIGINT NOT NULL,
  --
  CONSTRAINT BANDSONG_PK PRIMARY KEY (band_id, song_id),
  --
  CONSTRAINT BANDSONG_FK_TO_BAND FOREIGN KEY (band_id)
  REFERENCES band (band_id), 
  CONSTRAINT BANDSONG_FK_TO_SONG FOREIGN KEY (song_id)
  REFERENCES song (song_id)
);

 

Gjoer du det slik saa trenger du ikke aa sette opp en index for aa vaere sikker paa

at data ikke blir dobbeltlagret (i bandsong tabellen).

[roac]

Gjoer du det slik saa trenger du ikke aa sette opp en index for aa vaere sikker paa

at data ikke blir dobbeltlagret (i bandsong tabellen).

5995051[/snapback]

Rett meg gjerne hvis jeg tar feil, men jeg tror det er på sin plass med en liten presisering her (gitt at PostgreSQL oppfører seg på samme måtet som MSSQL her):

 

Når du oppretter en primærnøkkel blir det automatisk opprettet en indeks, så det som er tilfellet her er at du ikke trenger å opprette en indeks til, siden du allerede har en

[ofredstie]

Gjoer du det slik saa trenger du ikke aa sette opp en index for aa vaere sikker paa

at data ikke blir dobbeltlagret (i bandsong tabellen).

5995051[/snapback]

Rett meg gjerne hvis jeg tar feil, men jeg tror det er på sin plass med en liten presisering her (gitt at PostgreSQL oppfører seg på samme måtet som MSSQL her):

 

Når du oppretter en primærnøkkel blir det automatisk opprettet en indeks, så det som er tilfellet her er at du ikke trenger å opprette en indeks til, siden du allerede har en

5995915[/snapback]

 

Aa ja!! Det har du jo rett i!