Složený index pro tabulku vztahů

Řekněme, že se budeme držet používání automatického přírůstku id sloupec jako primární klíč. Nyní také musíme zajistit, aby data byla konzistentní, tj. , neexistují žádné duplicitní řádky pro kombinaci (student_id, course_id) hodnoty. Takže to budeme muset buď zpracovat v kódu aplikace (vybrat pokaždé před vložením/aktualizací), nebo to můžeme opravit strukturálně definováním kompozitního UNIQUE omezení na (student_id, course_id) .

Primární klíč je nyní v podstatě UNIKÁTNÍ NENULOVÝ klíč. Pokud se podíváte na definici tabulky, toto nově definované omezení UNIQUE je v podstatě pouze primárním klíčem (protože pole NEJSOU také NULL). Takže v tomto konkrétním případě opravdu nemusíte používat náhradní primární klíč id .

Rozdíl v režii během náhodného DML (Vložit/Aktualizovat/Odstranit) bude minimální, protože podobné režie byste měli také při použití pouze UNIQUE indexu. Můžete tedy spíše definovat přirozený primární složený klíč (student_id, course_id) :

-- Drop the id column
ALTER TABLE students_courses DROP COLUMN id;

-- Add the composite Primary Key
ALTER TABLE students_courses ADD PRIMARY(student_id, course_id);

Výše uvedené také vynutí omezení UNIQUE na kombinaci (student_id, course_id) . Navíc ušetříte 4 bajty na řádek (velikost int je 4 bajty). To se bude hodit, když budete mít velké stoly.

Nyní, když se připojujete od students na students_courses tabulka nad Primárním klíčem bude dostatečný index. Pokud se však potřebujete připojit z courses na students_courses tabulky, budete pro tento účel potřebovat další klíč. Takže můžete definovat ještě jeden klíč na course_id takto:

ALTER TABLE students_courses ADD INDEX (course_id);

Kromě toho byste měli definovat omezení cizího klíče, abyste zajistili integritu dat:

ALTER TABLE students_courses ADD FOREIGN KEY (student_id) 
                             REFERENCES students(student_id);

ALTER TABLE students_courses ADD FOREIGN KEY (course_id) 
                             REFERENCES courses(course_id);