Jak poprawnie tworzyć złożone klucze podstawowe - MYSQL

Oto rażące uproszczenie intensywnej konfiguracji, nad którą pracuję. table_1i table_2oba mają zastępcze klucze podstawowe z automatycznym zwiększaniem jako identyfikator. infoto tabela zawierająca informacje o obu table_1i table_2.

table_1 (id, field)  
table_2 (id, field, field)
info ( ???, field)

Próbuję zdecydować, czy powinienem zrobić klucz główny infozłożony z identyfikatorów z table_1i table_2. Gdybym to zrobił, który z nich ma największy sens?
(w tym przykładzie łączę ID 11209 z ID 437)

INT(9)11209437 (mogę sobie wyobrazić, dlaczego to jest złe)
VARCHAR (10) 11209-437
DECIMAL (10,4)11209.437

Albo coś innego?

Czy dobrze byłoby użyć tego jako klucza podstawowego w bazie danych MYYSAM DB MYSQL?

Użyłbym klucza złożonego (wielokolumnowego).

CREATE TABLE INFO (
    t1ID INT,
    t2ID INT,
    PRIMARY KEY (t1ID, t2ID)
) 

W ten sposób możesz mieć t1ID i t2ID jako klucze obce wskazujące również na ich odpowiednie tabele.

Nie uczyniłbym klucza podstawowego tabeli „informacji” złożonym z dwóch wartości z innych tabel.

Inni mogą lepiej przedstawić przyczyny, ale źle jest mieć kolumnę, która naprawdę składa się z dwóch informacji. Co jeśli chcesz z jakiegoś powodu posortować według identyfikatora z drugiej tabeli? Co jeśli chcesz policzyć, ile razy wartość z dowolnej tabeli jest obecna?

Zawsze trzymałbym je jako dwie odrębne kolumny. Możesz użyć dwukolumnowego klucza podstawowego w mysql ... KLUCZ PODSTAWOWY (id_a, id_b) ... ale wolę używać dwukolumnowego unikalnego indeksu i pola automatycznego klucza podstawowego.

składnia jest CONSTRAINT constraint_name PRIMARY KEY(col1,col2,col3)na przykład:

CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)

powyższy przykład będzie działał, jeśli piszesz go podczas tworzenia tabeli, na przykład:

CREATE TABLE person (
   P_Id int ,
   ............,
   ............,
   CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
);

aby dodać to ograniczenie do istniejącej tabeli, musisz przestrzegać następującej składni

ALTER TABLE table_name ADD CONSTRAINT constraint_name PRIMARY KEY (P_Id,LastName)

Załóżmy, że już utworzyłeś tabelę, teraz możesz użyć tego zapytania, aby utworzyć złożony klucz podstawowy

alter table employee add primary key(emp_id,emp_name);

Oprócz osobistych preferencji projektowych istnieją przypadki, w których chce się użyć złożonych kluczy podstawowych. Tabele mogą mieć dwa lub więcej pól, które zapewniają unikalną kombinację i niekoniecznie za pomocą kluczy obcych.

Na przykład, każdy stan USA ma zestaw unikalnych okręgów kongresowych. Chociaż wiele stanów może mieć CD-5 indywidualnie, nigdy nie będzie więcej niż jeden CD-5 w dowolnym z 50 stanów i odwrotnie. Dlatego utworzenie pola autonumerowania dla Massachusetts CD-5 byłoby zbędne.

Jeśli baza danych obsługuje dynamiczną stronę internetową, pisanie kodu do zapytania w kombinacji z dwoma polami może być znacznie prostsze niż wyodrębnianie / ponowne przesyłanie klucza z automatycznym kodowaniem.

Więc chociaż nie odpowiadam na pierwotne pytanie, z pewnością doceniam bezpośrednią odpowiedź Adama.

Złożone klucze podstawowe są tym, czego chcesz, tam gdzie chcesz utworzyć relację wiele do wielu z tabelą faktów. Na przykład możesz mieć pakiet wynajmu wakacyjnego, który zawiera wiele nieruchomości. Z drugiej strony nieruchomość może być również dostępna jako część szeregu pakietów najmu, zarówno samodzielnie, jak i z innymi nieruchomościami. W tym scenariuszu ustanawiasz związek między nieruchomością a pakietem wynajmu za pomocą tabeli faktów o nieruchomości / pakiecie. Powiązanie właściwości z pakietem będzie unikalne, dołączysz tylko za pomocą property_id z tabelą właściwości i / lub id_pakietu z tabelą pakietów. Każda relacja jest unikalna, a klucz auto_increment jest zbędny, ponieważ nie będzie występował w żadnej innej tabeli. Zatem zdefiniowanie klucza złożonego jest odpowiedzią.

CREATE  TABLE `mom`.`sec_subsection` (

  `idsec_sub` INT(11) NOT NULL ,

  `idSubSections` INT(11) NOT NULL ,

  PRIMARY KEY (`idsec_sub`, `idSubSections`) 

);

@AlexCuse Chciałem dodać to jako komentarz do twojej odpowiedzi, ale zrezygnowałem po wielu nieudanych próbach dodania nowego wiersza w komentarzach.

To powiedziawszy, t1ID jest unikalny w tabeli_1, ale to nie czyni go również unikalnym w tabeli INFO.

Na przykład:

Tabela_1 zawiera:
Identyfikator Pole
1 A
2 B

Tabela_2 ma:
Identyfikator Pole
1 X
2 Y

INFO może wtedy mieć:
t1ID pole t2ID
1 1 jakieś
1 2 dane
2 1 w każdym
2 2 rzędzie

Tak więc w tabeli INFO, aby jednoznacznie zidentyfikować wiersz, potrzebujesz zarówno t1ID, jak i t2ID