Первичный ключ в реляционных таблицах. Составной первичный ключ или уникальный первичный ключ в этих чистых реляционных таблицах?
Какой дизайн вы бы порекомендовали использовать в MySQL для повышения производительности? См. схему
Технические преимущества и недостатки!
Всем спасибо!
Это действительно зависит от типа запроса, который вы делаете...
Если вы добавите дополнительный суррогат, вам придется выполнять две уникальные проверки вместо одной для каждой вставки, обновления и удаления. Это заставляет композитный ключ звучать правильно.
Но если вы постоянно ссылаетесь на этот первичный ключ в других внешних ключах, составной вариант означает, что вы в конечном итоге храните в два раза больше информации и вам нужно выполнять больше работы при присоединении. Это заставляет единственный ключ звучать правильно.
Согласно Эльмасри и Навате (в Основах систем баз данных), вам следует выбрать вариант A, поскольку искусственные первичные ключи не нужны и предполагают, что у вас денормализованный дизайн (их POV).
В случае со сводной таблицей я согласен с авторами. В противном случае я думаю, что на практике использование искусственных ключей совершенно нормально.
Я не думаю, что последствия производительности для таблицы соединений огромны.
Я согласен с @Denis, это будет зависеть от того, что вы делаете. Еще одна вещь, которую следует учитывать, заключается в том, что InnoDB будет хранить строки на диске в порядке PK. Это очень важно, если вы делаете такие вещи, как id1 BETWEEN a AND b. Перемещение этих головок чтения занимает около 10 мс каждый раз, и если строки для вашего запроса разбросаны, они складываются. Именно по этим причинам вы можете подумать о денормализации, чтобы поместить нужные вам данные в одну строку.
