Indeksy w tabeli wiele-do-wielu Opcje

[rugby]

Jak najbardziej optymalnie rozwiązać taki problem:

Mam dwie table powiązane relacją wiele-do-wielu (many-to-many). Spinam je trzecią tabelą z kolumnami:
tab1_id, tab2_id, waga

Tab1_id wskazuje na id w tabeli 1, tab2_id na id w tabeli 2, waga to pewna liczba, wg której będę później sortował wyniki. Chcę, by relacje były unikatowe, czyli nie było dwóch rekordów o tych samych tab1_id i tab2_id łącznie.

Ile i jakie ustawić indeksy w tej trzeciej tabeli? Czy bardziej wydajne jest stworzenie trzech zwykłych indeksów na kolumny: tab1_id, tab2_id, waga, czy lepiej dwa indeksy (jeden unikatowy kompozytowy na kolumny: tab1_id, tab2_id i drugi zwykły na kolumnę waga), czy może lepiej cztery (trzy zwykłe na kolumny: tab1_id, tab2_id, waga i czwarty unikatowy kompozytowy na kolumny: tab1_id, tab2_id)?

Najczęstsze zapytania będą typu:

[SQL] pobierz, plaintext 
SELECT tab2.* FROM tab2 INNER JOIN tab3 ON tab2.id=tab3.tab2_id WHERE tab3.tab1_id=1 ORDER BY waga
[SQL] pobierz, plaintext 

Jak ilość indeksów wpływa na wielkość bazy przy bardzo dużej liczbie rekordów?

Ten post edytował rugby 9.07.2009, 16:11:59

[maly_swd]

najprosciej dodaj indexu unikalne na te wartosci ktore sa unikalne:) czyli ID.. drugie zobacz co mowi magiczne EXPLAIN.

A co do obietosci bazy.. to ona sie nie zwieksza... baza to baza, a indexy to indexy.. wiec pliki z indexem beda wiecej zajmowaly:)

[rugby]

Ok, utworzę index unikatowy kompozytowy na (tab1_id, tab2_id), ale czy opłaca się wtedy stworzyć drugi indeks na wagę, jeśli będę sortował wg niej? Jeśli rekordów przybędzie powiedzmy n, to te dwa pliki indeksów zwiększą się 2*n-krotnie, zgadza się?