Klucz obcy SQL, który jest częścią złożonego klucza podstawowego

Question

Czy jest możliwe, aby klucz obcy tabeli był częścią złożonego klucza podstawowego innej tabeli? Na przykład, jeśli mam dwie tabele, jedna zawiera informacje o wszystkich aktywnych projektów różnych użytkowników i innym zawierającym informacje o jaki sprzęt jest używany przez projekty:

Tabela Projekt:

Composite Primary Keys: UserId, ProjectId (nie są unikalne przez siebie)

Equipment tabeli:

Composite Primary Keys: UserId, ProjectId, EquipmentId (nie są unikalne same)

teraz jest pO ssible, aby ustawić ProjectId w tabeli sprzętu na klucz obcy z tabeli projektu? Kiedy próbuję, pojawia się błąd informujący, że kolumna w tabeli projektu nie pasuje do istniejącego klucza głównego lub ograniczenia unikalnego?

Answer 1

nr

Podczas tworzenia klucz obcy, klucz, że „punkt” w drugim stole musi być UNIQUE albo ograniczenie PRIMARY KEY. Nie można ustanowić klucza obcego wskazującego kolumnę, która zezwala na powielanie wartości. Byłoby bardzo trudno wyobrazić sobie, jak dane powinny "działać", jeśli zaktualizujesz jedną z duplikatów w drugiej tabeli (na przykład).

Aby zrobić to, co chcesz, musisz utworzyć tabelę projektów, w której ProjectID jest UNIQUE lub klucz podstawowy, a następnie wskazywać klucze obce w zarówno innych tabel do tej tabeli.

Nawiasowo używa się terminu "Klucze podstawowe" do opisu kolumn w każdej tabeli, która składa się na klucz podstawowy. W rzeczywistości każda tabela może mieć jeden i tylko jeden klucz podstawowy. Ten klucz może składać się z jednej lub więcej kolumn, ale sam klucz jest nadal określany jako pojedynczy. Jest to ważna różnica przy korzystaniu z klucza podstawowego w celu optymalizacji wyszukiwań.

Answer 2

@Larry Lustig Klucz obcy może być częścią klucza podstawowego w drugiej tabeli.

źródło: Dependent relationship

Sprawdź relacje między tabelami: ZDARZENIE (Event) i TypZdarzenia (rodzaj zdarzenia)

Answer 3

Nie wiem, czy to jest dobre praktyki projektowania, ale na pewno to można mieć złożony klucz obcy jednej tabeli, która jest częścią złożonego klucza podstawowego innej tabeli.

że mamy test1 tablica zawierająca kompozytową klucza podstawowego (A, B)

Teraz znajduje się stół powiedzieć TEST2 posiadające klucz podstawowy (P, Q, R), gdzie (p, q) odniesienie test2 (A, B) testu 2.

Uruchomiłem następujący skrypt w bazie danych MySql i działa dobrze.

CREATE TABLE `test1` (
`A` INT NOT NULL, 
`B` VARCHAR(2) NOT NULL, 
`C` DATETIME NULL, 
`D` VARCHAR(45) NULL, 
PRIMARY KEY (`A`, `B`)); 

CREATE TABLE `test2` (
`P` INT NOT NULL, 
`Q` VARCHAR(2) NOT NULL, 
`R` INT NOT NULL, 
`S` DATETIME NULL, 
`T` VARCHAR(8) NULL, 
PRIMARY KEY (`P`, `Q`, `R`), 
INDEX `PQ_idx` (`P`,`Q` ASC), 
CONSTRAINT `PQ` 
    FOREIGN KEY (`P`, `Q`) 
    REFERENCES `test1` (`A`,`B`) 
    ON DELETE CASCADE 
    ON UPDATE CASCADE); 

W wyżej wymienionym przypadku, baza danych spodziewa kombinację (A, B), aby być unikalny i to, że jest kluczem podstawowym w tabeli test1.

Ale jeśli spróbujesz zrobić coś takiego po skrypt zawiedzie. Baza danych nie pozwoli Ci utworzyć tabeli test2.

CREATE TABLE `test2` (
`P` INT NOT NULL, 
`Q` VARCHAR(2) NULL, 
`R` DATETIME NULL, 
`S` VARCHAR(8) NULL, 
`T` VARCHAR(45) NULL, 
    INDEX `P_idx` (`P` ASC), 
    INDEX `Q_idx` (`Q` ASC), 
    CONSTRAINT `P` 
    FOREIGN KEY (`P`) 
    REFERENCES `test1` (`A`) 
    ON DELETE CASCADE 
    ON UPDATE CASCADE, 
    CONSTRAINT `Q` 
    FOREIGN KEY (`Q`) 
    REFERENCES `test1` (`B`) 
    ON DELETE CASCADE 
    ON UPDATE CASCADE); 

W przypadku wyżej wymienionych danych oczekiwać kolumna A, która będzie wyjątkowa indywidualnie i tym samym następuje na kolumnie B. Nie ma znaczenia, czy połączenie (A, B) jest unikalny.