Come indicizzare correttamente una tabella di associazione many many?

Question

In una tipica disposizione molti-molti come questo ...

 
Movies  Actors  Movies_Actors 
------  ------  ------------- 
movie_ID  actor_ID  FK_movie_ID 
title  name   FK_actor_ID 

... come dovrebbe la tabella di associazione ('Movies_Actors') indicizzati per la velocità di lettura ottimale?

solito vedere questo fatto solo con la chiave primaria composta nella tabella di associazione, in questo modo:

CREATE TABLE Movies_Actors (
    FK_movie_ID INTEGER, 
    FK_actor_ID INTEGER, 
    PRIMARY KEY (FK_movie_ID, FK_actor_ID) 
) 

Tuttavia, questa sembra l'indice sarà utile solo quando si cerca siamovie_ID e actor_ID (anche se non sono sicuro se un indice composito funzioni anche per le singole colonne).

Poiché sia ​​"Quelli che sono attori in Film X" sia "In quali film è presente l'attore Y" saranno le domande frequenti su questo tavolo, sembra che ci dovrebbe essere un indice individuale su ogni colonna per individuare rapidamente gli attori e film per conto proprio. Un indice composito lo fa in modo efficace? In caso contrario, avere un indice composito sembra inutile su questo tavolo. E se un indice composito è inutile, che fare con una chiave primaria? La chiave candidata è chiaramente il composto delle due colonne, ma se l'indice composito risultante è inutile (non deve essere?) Sembra uno spreco.

Inoltre, this link aggiunge confusione e indica che potrebbe anche essere utile per specificare effettivamente due indici composti ... uno come (FK_movie_ID, FK_actor_ID), e l'altra in senso inverso come (FK_actor_ID, FK_movie_ID), con la scelta dei quali è il chiave primaria (e quindi di solito cluster) e che è 'solo' un indice composito univoco basato su quale direzione viene interrogata di più.

Qual è la vera storia? Un indice composito indicizza automaticamente in modo efficace ogni colonna per la ricerca su uno o l'altro? La tabella di associazione ottimale (in velocità di lettura, non in dimensione) ha un indice composito in ciascuna direzione e uno su ogni colonna? Quali sono i meccanici dietro le quinte?

---

EDIT: Ho trovato questa domanda correlata che per qualche motivo non mi ha individuato prima di pubblicare ... How to properly index a linking table for many-to-many connection in MySQL?

Answer 1

(anche se non sono certo se un indice composito funziona anche singole colonne).

Sì, è possibile. Ma solo il prefisso: http://use-the-index-luke.com/sql/where-clause/the-equals-operator/concatenated-keys

Inoltre, questo collegamento aggiunge confusione e indica che potrebbe anche essere utile effettivamente specificare due indici composti ...uno di loro come (FK_movie_ID, FK_actor_ID), e l'altra in senso inverso come (FK_actor_ID, FK_movie_ID),

Che in realtà è la cosa da fare.

Prendere uno come indice di clustering e l'altro come indice non di clustering che includerà comunque la chiave dell'indice di clustering, quindi non è necessario includere nuovamente quella colonna (da thx a JNK).

CREATE CLUSTERING INDEX a on Movies_Actors (fk_movie_id, fk_actor_id); 
CREATE NONCLUSTERING INDEX b on Movies_Actors (fk_actor_id); 

Qual è la vera storia?

http://Use-The-Index-Luke.com/ :)

Fa un indice composito automaticamente indice in modo efficace ogni colonna per ricerca su uno o l'altro?

No. Solo il prefisso dell'indice. Se hai un indice (a, b, c), la query a =? e b =? può usare l'indice Tuttavia c =? non può, né può b =? e c = ?.

Qualora l'ottimale (in velocità di lettura, non formato) tabella di associazione hanno un indice composito in ogni direzione e uno su ogni colonna?

Se è necessario unire in entrambe le direzioni, sì ("indice composito in ogni direzione") e no ("uno su ogni colonna").

Quali sono i meccanismi dietro le quinte?

Bene, stesso collegamento di nuovo.

Parlando di SQL Server, si potrebbe anche considerare una vista indicizzata. È una sorta di pre-iscrizione. Due indici, come sopra, potrebbero anche essere abbastanza veloci.

Answer 2

In SQL Server, un indice composito può essere utilizzato per una singola ricerca di campo per la prima colonna solo. Ciò significa che dovresti avere un ulteriore indice di campo su FK_actor_id se ci saranno ricerche su quel campo senza FK_Movie_id nella stessa query.