Як правильно створити складені первинні ключі - 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. Якби я це робив, який із них має найбільше значення?
(у цьому прикладі я поєдную ідентифікатор 11209 з ідентифікатором 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 як зовнішні ключі, що вказують і на їхні відповідні таблиці.

Я б не робив первинний ключ таблиці "інформація" складовим з двох значень з інших таблиць.

Інші можуть сформулювати причини краще, але відчуває себе неправильно мати стовпчик, який справді складається з двох відомостей. Що робити, якщо ви хочете чомусь відсортувати ідентифікатор з другої таблиці? Що робити, якщо ви хочете порахувати кількість присутніх значень з будь-якої таблиці?

Я б завжди зберігав це як два чіткі колонки. Ви можете використати клавішу primay з двома стовпцями в 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, і навпаки. Тому створити поле для авточислення для Massachusetts CD-5 було б зайвим.

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

Тому, поки я не відповідаю на початкове запитання, я, безумовно, ціную пряму відповідь Адама.

Композиційні первинні ключі - це те, що ви хочете, коли ви хочете створити взаємозв'язок багато-багато з таблицею фактів. Наприклад, у вас може бути пакет оренди для відпустки, який включає в себе ряд властивостей. З іншого боку, власність також може бути доступною у складі ряду пакетів оренди як самостійно, так і з іншими властивостями. У цьому випадку ви встановлюєте взаємозв’язок між майном та орендною орендою з таблицею фактів властивості / пакету. Асоціація між властивістю та пакетом буде унікальною, ви завжди будете приєднуватися, використовуючи property_id разом із таблицею властивостей та / або package_id з таблицею пакетів. Кожне відношення є унікальним, а ключ автопосилення є зайвим, оскільки він не відображатиметься в будь-якій іншій таблиці. Отже, визначення складового ключа - відповідь.

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

INFO тоді може мати:
t1ID t2ID поле
1 1 деякі
1 2 дані
2 1 у кожному
2 2 рядку

Тож у таблиці INFO для унікального визначення рядка вам потрібно як t1ID, так і t2ID