Как правильно создавать составные первичные ключи - MYSQL

Вот грубое упрощение интенсивной установки, с которой я работаю. table_1и table_2оба имеют автоинкрементные суррогатные первичные ключи в качестве идентификатора. infoэто таблица, которая содержит информацию о обоих table_1и table_2.

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

Я пытаюсь решить, должен ли я сделать первичный ключ из infoнабора идентификаторов из table_1и table_2. Если бы я сделал это, какой из них имеет больше смысла?
(в этом примере я объединяю ID 11209 с ID 437)

INT(9)11209437 (я могу представить, почему это плохо)
VARCHAR (10) 11209-437
DECIMAL (10,4)11209.437

Или что-то другое?

Было бы хорошо использовать это в качестве первичного ключа в базе данных MYSQL MYISAM?

Я бы использовал составной (многостолбцовый) ключ.

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

Таким образом, вы можете иметь t1ID и t2ID в качестве внешних ключей, указывая также на их соответствующие таблицы.

Я бы не стал делать первичный ключ таблицы «info» составным из двух значений из других таблиц.

Другие могут лучше сформулировать причины, но неправильно иметь столбец, состоящий из двух частей информации. Что делать, если вы хотите по какой-то причине отсортировать по идентификатору из второй таблицы? Что если вы хотите посчитать, сколько раз значение из любой таблицы присутствует?

Я бы всегда держал их как две отдельные колонки. Вы можете использовать первичный ключ с двумя столбцами в mysql ... PRIMARY KEY (id_a, id_b) ... но я предпочитаю использовать уникальный индекс из двух столбцов и иметь поле первичного ключа с автоматическим приращением.

синтаксис, CONSTRAINT constraint_name PRIMARY KEY(col1,col2,col3)например:

CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)

приведенный выше пример будет работать, если вы пишете его во время создания таблицы, например:

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

чтобы добавить это ограничение в существующую таблицу, вам нужно следовать следующему синтаксису

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

Предположим, вы уже создали таблицу, теперь вы можете использовать этот запрос для создания составного первичного ключа.

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

Помимо личных предпочтений дизайна, есть случаи, когда кто-то хочет использовать составные первичные ключи. Таблицы могут иметь два или более полей, которые предоставляют уникальную комбинацию, и необязательно посредством внешних ключей.

Например, в каждом штате США есть набор уникальных округов Конгресса. Хотя во многих штатах CD-5 может быть отдельно, в любом из 50 штатов никогда не будет более одного CD-5, и наоборот. Поэтому создание поля автонумерации для Массачусетса CD-5 было бы излишним.

Если база данных управляет динамической веб-страницей, написание кода для запроса по комбинации из двух полей может быть намного проще, чем извлечение / повторная передача ключа с автонумерацией.

Поэтому, хотя я не отвечаю на первоначальный вопрос, я, безусловно, ценю прямой ответ Адама.

Составные первичные ключи - это то, что вам нужно, когда вы хотите создать связь «многие ко многим» с таблицей фактов. Например, у вас может быть пакет аренды на время отпуска, который включает в себя ряд свойств. С другой стороны, недвижимость также может быть доступна как часть ряда пакетов аренды, либо самостоятельно, либо вместе с другими объектами. В этом сценарии вы устанавливаете связь между свойством и пакетом аренды с помощью таблицы фактов свойства / пакета. Связь между свойством и пакетом будет уникальной, вы можете присоединиться только с помощью property_id с таблицей свойств и / или package_id с таблицей пакетов. Каждое отношение уникально, и ключ auto_increment является избыточным, поскольку он не будет отображаться ни в одной другой таблице. Следовательно, определение составного ключа является ответом.

CREATE  TABLE `mom`.`sec_subsection` (

  `idsec_sub` INT(11) NOT NULL ,

  `idSubSections` INT(11) NOT NULL ,

  PRIMARY KEY (`idsec_sub`, `idSubSections`) 

);

@AlexCuse Я хотел добавить это как комментарий к вашему ответу, но сдался после нескольких неудачных попыток добавить новые строки в комментарии.

Тем не менее, t1ID уникален в table_1, но это не делает его уникальным и в таблице INFO.

Например:

Таблица_1 содержит:
Id Поле
1 A
2 B

Таблица_2 имеет:
Id Поле
1 X
2 Y

ИНФО затем может иметь:
t1ID t2ID поле
1 1 какой-то
1 2 данных
2 1 в каждой
2 2 строке

Таким образом, в таблице INFO для уникальной идентификации строки вам нужны и t1ID, и t2ID.