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

Вот грубое упрощение интенсивной настройки, с которой я работаю. table_1 и table_2 оба имеют 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 DB?

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

     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) 

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

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

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

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

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

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

     alter table employee add primary key(emp_id,emp_name); 
     CREATE TABLE `mom`.`sec_subsection` ( `idsec_sub` INT(11) NOT NULL , `idSubSections` INT(11) NOT NULL , PRIMARY KEY (`idsec_sub`, `idSubSections`) ); 

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

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

    Например:

    Таблица_1 имеет:
    Поле идентификатора
    1 A
    2 B

    В таблице_2 есть:
    Поле идентификатора
    1 X
    2 Y

    Затем INFO может иметь:
    Поле t1ID t2ID
    1 1 некоторые
    1 2 данные
    2 1 в каждом
    2 2 ряда

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

    Давайте будем гением компьютера.