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