Этот вопрос возникает после прочтения комментария к этому вопросу:
Когда вы создаете таблицу «многие ко многим», следует ли вам создать составной первичный ключ для двух столбцов внешнего ключа или создать суррогатный первичный ключ «ID» с автоинкрементом и просто поместить индексы в два столбца FK (и, возможно, уникальное ограничение)? Каково влияние на производительность вставки новых записей / повторной индексации в каждом случае?
В основном это:
PartDevice
----------
PartID (PK/FK)
DeviceID (PK/FK)против этого:
PartDevice
----------
ID (PK/auto-increment)
PartID (FK)
DeviceID (FK)Комментатор говорит:
превращение двух идентификаторов в PK означает, что таблица физически сортируется на диске в указанном порядке. Итак, если мы вставим (Part1 / Device1), (Part1 / Device2), (Part2 / Device3), тогда (Part 1 / Device3) базе данных придется разбить таблицу на части и вставить последнюю между записями 2 и 3. Для При большом количестве записей это становится очень проблематичным, поскольку требует перетасовки сотен, тысяч или миллионов записей при каждом добавлении одной. Напротив, автоинкрементный PK позволяет прикреплять новые записи до конца.
Причина, по которой я спрашиваю, заключается в том, что я всегда был склонен использовать составной первичный ключ без суррогатного столбца с автоинкрементом, но я не уверен, действительно ли суррогатный ключ более эффективен.
источник
Ответы:
При простом отображении «многие ко многим» из двух столбцов я не вижу реальных преимуществ в наличии суррогатного ключа. Имея первичный ключ на
(col1,col2)гарантированно уникальном (предполагается , чтоcol1иcol2значение в справочных таблицах являются уникальным) и отдельным индексом на(col2,col1)поймаете те случаи , когда порядок напротив будет выполнять быстрее. Суррогат - пустая трата места.Вам не понадобятся индексы для отдельных столбцов, так как таблица должна использоваться только для объединения двух таблиц, на которые есть ссылки.
На мой взгляд, этот комментарий, на который вы ссылаетесь в вопросе, не стоит тех электронов, которые он использует. Похоже, автор думает, что таблица хранится в массиве, а не в чрезвычайно высокопроизводительной сбалансированной многосторонней древовидной структуре.
Во-первых, никогда не нужно сохранять или получать отсортированную таблицу , только индекс. И индекс не будет сохраняться последовательно, он будет сохранен эффективно, чтобы его можно было быстро получить.
Кроме того, читается подавляющее большинство таблиц базы данных. гораздо чаще, чем записываются. Это делает все, что вы делаете на стороне выбора, гораздо более актуальным, чем что-либо на стороне вставки.
источник
insertхочу сказать , будет ли это иметь значение, если это будет выполняться тысячи раз в час. Вы не можете просто игнорировать его только потому, что отношениеinsertкselect<1. В этом случае покупатель заботится о том, сколько времени уходит на размещение заказа.Для таблиц ссылок суррогатный ключ не требуется.
Один ПК на (col1, col2) и еще один уникальный индекс на (col2, col1) - это все, что вам нужно
Если вы не используете ORM, который не справляется и не диктует вам дизайн вашей БД ...
Изменить: я ответил то же самое здесь: SQL: вам нужен автоинкрементный первичный ключ для многих-многих таблиц?
источник
(col2, col1)нет(col1, col2). PK of(col1, col2)может не подходить для всех запросов и генерировать сканирование, поэтому использование обратного действия улучшает производительность, поскольку позволяет искать там, где col2 лучше. Например, проверка FK, когда таблица с col2 имеет удаление. Загрязнение дочерней таблицы должно быть провереноЕсли есть ссылка на таблицу, может потребоваться инкрементный первичный ключ. В таблице «многие ко многим» могут быть детали, которые необходимо извлечь из другой таблицы с помощью инкрементного первичного ключа.
например
«Прочие детали» легко получить, используя PartDevice.ID в качестве FK. Таким образом, необходимо использовать инкрементный первичный ключ.
источник
Самый короткий и прямой способ ответить на ваш вопрос - это сказать, что производительность будет снижаться, если две таблицы, которые вы связываете, не имеют последовательных первичных ключей. Как вы заявили / цитировали, индекс для таблицы ссылок либо станет фрагментированным, либо СУБД будет труднее вставлять записи, если таблица ссылок не имеет своего собственного последовательного первичного ключа. По этой причине большинство людей помещают последовательно увеличивающийся первичный ключ в таблицы ссылок.
источник
Таким образом, похоже, что если ЕДИНСТВЕННАЯ задача - связать две таблицы, лучшим ПК будет ПК с двумя столбцами.
Но если он служит другим целям, добавьте еще один NDX в качестве PK с внешними ключами и вторым уникальным индексом.
Индекс или PK - лучший способ убедиться в отсутствии дубликатов. PK позволяет таким инструментам, как Microsoft Management Studio, выполнять часть работы (создавать представления) за вас.
источник