MySQL. Первичный ключ в реляционной таблице. Уникальный идентификатор или несколько уникальных ключей?

Question

Первичный ключ в реляционных таблицах.Составной первичный ключ или уникальный первичный ключ в этих чистых реляционных таблицах?

Какой дизайн вы бы порекомендовали использовать в MySQL для высокой производительности? См. Диаграмму

Технические преимущества и недостатки!

Спасибо всем!

Answer 1

Это действительно зависит от типа запроса, который вы делаете ...

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

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

Answer 2

Я согласен с @Denis, это будет зависеть от того, что вы делаете. Еще одна вещь, которую следует учитывать, это то, что InnoDB будет хранить строки в порядке PK на диске. Это очень важно, если вы делаете такие вещи, как id1 BETWEEN a AND b. Перемещение этих считывающих головок составляет около 10 мс каждый раз, и если строки для вашего запроса разбросаны, это сложится. Именно по этим причинам вы можете подумать о денормализации, чтобы поместить нужные данные в одну строку.

Answer 3

Согласно Elmasri и Navathe (в Основы систем баз данных ), вам следует выбрать вариант A, потому что искусственные первичные ключи не нужны и предполагают, что у вас денормализованный дизайн (их POV).

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

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