Ефективність складного первинного ключа як зовнішній ключ

12

У мене є таблиця з складеним первинним ключем (що складається з 4 стовпців), яка використовується для того, щоб у таблицю не було введено дублікатів. Мені зараз потрібна нова таблиця, яка повинна посилатися на ключі в цій таблиці як на сторонні ключі.

Моє запитання - який підхід є більш ефективним для швидкості пошуку:

1) Чи я створюю нову таблицю, включаючи всі 4 стовпці, і посилаю їх усі на іноземному ключі.

або

2) Чи створюю новий стовпець ідентичності в таблиці Первинний ключ і чи використовую це як зовнішній ключ у новій таблиці.

Очікується, що ця база даних вміщатиме дуже великий об'єм даних, тому я створив її до цих пір, щоб мінімізувати кількість даних, що містяться в кожній таблиці. Зважаючи на це, варіант 2 був би найкращим підходом, оскільки я зберігатиму 2 стовпчики int та стовпець datetime для кожного рядка, але я хочу уникати збільшення часу пошуку, якщо це не потрібно.

— аарокатлін
джерело

1

Я особисто завжди завжди використовував би сурогатний ключ (наприклад, an INT IDENTITY) у такому випадку - значно спрощує посилання та приєднання до цієї таблиці просто soooooo. Щоб уникнути дублікатів, поставте UNIQUE обмеження на ці чотири стовпці. Також: вузькі первинні ключі набагато краще з міркувань продуктивності (якщо вони використовуються як кластерний ключ)

— marc_s

11

Вартість використання простого синтетичного цілого PK невелика, і користь у вашому випадку, ймовірно, буде досить значною.

Як ви зазначаєте, у вас будуть набагато простіші відносини з ФК
Невеликий ПК складає малі (і швидкі) індекси. Мабуть, ваш загальний простір таблиці зменшиться, додавши такий стовпець.
Якщо правила бізнесу колись змінюватимуться, вам не доведеться переробляти таблицю.

Єдиний недолік, що виникає на увазі, - це те, що ви можете втратити продуктивність щодо запитів, які виграли від кластеризації на складеному ПК. Якщо ви вважаєте, що це, ймовірно, буде суттєво, ніж продовжуйте кластеризацію на складеному ключі-кандидаті, але додайте ПК на синтетичний ключ.

— Йон усіх торгів
джерело

5

Як часто в світі SQL, відповідь така: "Це залежить".

Погляньте на це запитання щодо деяких покажчиків: Чи забезпечують природні ключі більш високу чи нижчу продуктивність у SQL Server, ніж сурогатні цілі клавіші?

Бувають випадки, коли покращення продуктивності спостерігається при використанні природних ключів як зовнішніх клавіш. Однак у більшості випадків вам стане краще з меншими клавішами (читайте: сурогатні ключі).

Якщо ви введете цей стовпець ІДЕНТИЧНОСТІ, я б навіть зробив його Первинним ключем і змінив "природні" стовпці, щоб натомість був УНІКАЛЬНИМ ОБМЕЖЕННЯМ.

— Себастьян Мейн
джерело