У мене є таблиця з чотирма стовпцями, які всі не нульові, і дані такі, що всі чотири потрібні для розрізнення унікального запису. Це означає, що якби я створив первинний ключ, він повинен містити всі стовпці. Запити до таблиці майже завжди полягатимуть у тому, щоб повернути один запис назад, тобто всі стовпці будуть відфільтровані в запиті.
Оскільки в кожному стовпчику потрібно буде шукати, чи має користь для мене первинний ключ взагалі (окрім забезпечення унікальності записів)?
Відповіді:
У вашому випадку ці поля є природним ключем.
Сурогатний ключ:
Сурогатні ключі - це ключі, що не мають "ділового" значення і використовуються виключно для ідентифікації запису в таблиці. Такі ключі або генеруються базами даних (наприклад: Ідентифікація на SQL Server, Послідовність у Oracle, Послідовність / Ідентичність у DB2 UDB тощо), або системними значеннями (як, наприклад, згенеровано за допомогою таблиці на схемі).
Природний ключ:
Клавіші є природними, якщо атрибут, який він представляє, використовується для ідентифікації незалежно від схеми бази даних. Це в основному означає, що ключі є природними, якщо люди використовують їх, наприклад: рахунки-номери рахунків, податкові ідентифікатори, SSN тощо.
Сурогатні ключі проти природних ключів для первинного ключа
Я віддаю перевагу додавати сурогатний ключ, щоб розділити управління бізнесом та моделлю баз даних. Інше питання полягає у використанні кластерного та некластеризованого індексу на первинному ключі. Якщо ви внесете зміни в таблицю (нестатична таблиця, вона має інтенсивні вставки або оновлення), ви отримаєте проблему з продуктивністю у разі використання кластерного індексу на немонотонному збільшеному ключі.
Зазвичай рекомендується мати сурогатний ключ у таких ситуаціях, тому сторонні ключі в інших таблицях (і будь-які посилання на записи, які можуть зберігатися зовні, наприклад, якщо вони переносяться на рядки запитів, де запит http (s) посилається на один записів) є на що посилатися, що не зміниться, якщо змінити дані ряду. Якщо ви це зробите, то це буде вашим первинним ключем.
Якщо ви не додаєте такий сурогатний ключ, то, враховуючи, як ви описуєте дані, що мають доступ, що мають усі чотири стовпці як основний ключ, це не буде недоліком. Якщо ввести ключ кластерного індексу для таблиці, він допоможе таким запитам, оскільки на b-дереві на диску буде один рівень, щоб знизити дані для даного рядка.
Композиційні клавіші як первинні ключі також стикаються з проблемами розміру індексу, які можуть впливати на використання диска, швидкості io та резервні копії. Ви можете переглянути публікації Кімберлі Трипп про первинні ключі та кластерні індекси тут: http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-again!.aspx
Я теж запропонував би сурогатний ключ у цьому випадку замість природного.
Якщо у вас є таблиця, що представляє багатозахисні стосунки, які містять всього 2 стовпчики, це здається розумним.
Ср. це питання
Але я визнаю, що додаю сурогатні ключі навіть у тих випадках.