ORM предписывают использование несоставных первичных ключей для упрощения запросов ...
Но это делает запросы проще ...
На первый взгляд, это делает удаление или обновлениеконкретный заказ / и т. д. проще - пока вы не поймете, что вам нужно знать соответствующее значение идентификатора сначала .Если вам нужно искать это значение идентификатора на основе специфики заказа, вам лучше было бы использовать критерии непосредственно в первую очередь.
Но составные ключи сложны ...
В этом примере ограничение первичного ключа гарантирует, что два столбца - fkProductID и fkOrderID - будут уникальными и проиндексированными (большинство БД в наши дни автоматически индексируют первичные ключи, если кластерный индекс еще не существует), используя лучший индексможно за столом.
Подход одиночного первичного ключа означает, что OrderDetailsID индексируется с наилучшим индексом для таблицы (SQL Server и MySQL называют их кластерными индексами, для Oracle они все являются просто индексами) и требуют дополнительного составногоуникальное ограничение / индекс.Для некоторых баз данных может потребоваться дополнительная индексация, выходящая за пределы уникального ограничения ... Таким образом, это делает модель данных более сложной / сложной и бесполезной:
- В некоторых базах данных, таких как MySQL, установлено ограничение на количествопространства, которое вы можете использовать для индексов.
- первичный ключ получает наиболее идеальный индекс, но значение не имеет отношения к данным в таблице, поэтому использование индекса, связанного с первичным ключом, будет редкоесли вообще.
Заключение
Я не вижу преимущества в первичном ключе с одним столбцом по сравнению с составным первичным ключом.Больше работы для дополнительных накладных расходов без чистой выгоды ...