SQL - первичный ключ таблицы «многие ко многим»
Этот вопрос возникает после прочтения комментария к этому вопросу:
При создании таблицы «многие ко многим» следует создать составной первичный ключ для двух столбцов внешнего ключа или создать первичный ключ с автоматическим приращением суррогатного идентификатора «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 позволяет добавлять новые записи до конца.
Причина, по которой я спрашиваю, заключается в том, что я всегда был склонен делать составной первичный ключ без столбца суррогатного автоинкремента, но я не уверен, что суррогатный ключ действительно более производительный.