W relacyjnych bazach danych relacja wiele‑do‑wielu (m:n) nie jest zwykle implementowana jako pojedyncze "bezpośrednie" powiązanie dwóch tabel, ponieważ prowadzi to do problemów z powtarzaniem informacji i trudnością w utrzymaniu spójności.
Poprawnym podejściem jest utworzenie tabeli pośredniej (łącznikowej, pomocniczej). Taka tabela przechowuje pary powiązań, najczęściej w postaci dwóch kolumn będących kluczami obcymi do obu tabel. W praktyce często tworzy się w niej klucz główny złożony z tych dwóch kluczy obcych albo stosuje osobny identyfikator i unikalność pary.
Dlaczego to ogranicza redundancję? Ponieważ każda informacja o powiązaniu występuje tylko raz: wiersz w tabeli pośredniej oznacza jedno skojarzenie rekordu z tabeli A z rekordem z tabeli B. Dzięki temu nie trzeba powielać kolumn ani tworzyć wielokrotnych, powtarzających się zestawów danych w jednej z tabel.
Odpowiedź "posortować przynajmniej jedną z tabel" jest błędna, bo sortowanie dotyczy prezentacji wyników zapytań, a nie struktury relacji i nie wpływa na eliminację redundancji w schemacie.
Odpowiedzi o "bezpośrednim połączeniu kluczy obcych" lub "bezpośrednim połączeniu kluczy podstawowych" są mylące: w relacyjnym modelu nie "łączy się kluczy" jako operacji projektowej, tylko definiuje się kolumny oraz ograniczenia (np. klucze obce) w konkretnych tabelach. Bez tabeli pośredniej nie uzyska się poprawnego i elastycznego odwzorowania m:n.
W kontekście aplikacji internetowych (INF.3) to podejście jest kluczowe np. dla relacji użytkownicy–uprawnienia, produkty–kategorie czy posty–tagi.
