Чи повинен ключ розділу також бути частиною первинного ключа?

Я розділяю таблицю на основі стовпця, який не є первинним ключем? Я сьогодні прочитав деяку суперечливу інформацію про те, чи повинен стовпчик розділу бути частиною первинного ключа. Моя кишка каже "ні", але я не впевнений на 100%. Тож питання ...

Чи повинен стовпчик розділу бути частиною основного? Рекомендується так чи інакше?
Чи потрібно створити індекс для ключа розділу чи СУБД робить це автоматично самостійно?

— AngryHacker
джерело

Відповіді:

Зовсім ні.

Один з найпоширеніших сценаріїв для розділення - використання поля дати, яке абсолютно не пов'язане з ПК.

Наприклад, якщо у вас є таблиця Ordersз полем, OrderDateви, швидше за все, розділите на основі місяця та року OrderDate.

Якщо записи старіють і вже не є актуальними, ви можете перемістити ці розділи в архівну таблицю або базу даних, щоб вони більше не оброблялися.

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

EDIT

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

— JNK
джерело

Я знаю, що це старе, але це веде мене неправильним шляхом, тому я думав, що буду коментувати інших. Стовпець розділів повинен бути в первинному ключі, якщо ви хочете використовувати можливості SWITCH функції Partition. Якщо його немає в первинному ключі, ви отримаєте цю помилку: Partition columns for a unique index must be a subset of the index key.

— Vaccano

Я згоден з @Vaccano

— сан

Окрім відповіді JNK, ви, ймовірно, повинні прочитати цю статтю, в якій обговорюється вирівнювання розділів таблиці та розділів індексів.

Існує багато типів сценаріїв, коли схема розподілу точно слідує першому стовпцю первинного ключа - наприклад, у сценарії сховища даних, де дата зйомки таблиці фактів зазвичай є стовпцем розділу, а також першим стовпцем у первинному ключі.

Але в рівних випадках у середовищах OLTP, де ПК є ідентифікатором або іншим сурогатним ключем, мало сенсу використовувати це для розділу, оскільки розділення на довільні числа зазвичай не дуже корисно. В системах OLTP ви також схильні до найбільшого розподілу за датою (можливо, це не в ПК), але, можливо, також регіонально або через якийсь організаційний поділ (можливо, в ПК, якщо ви не використовуєте сурогат)

Але це не вимога.

— Кейд Ру
джерело

Що ж, ціла маса речі - це не вимога. Навіть індексація не є вимогою! Щоб мати сенс функціонально, розділення повинно бути виконано на провідному стовпчику ключа-кандидата. Інакше як архітектор додатків використовував таблицю?

— srini.venigalla

@ srini.venigalla Це звичайний випадок, але інший поширений випадок (однаково так?) - це розділ на те, що взагалі не є частиною первинного або кандидатського ключа - оскільки розділення часто використовується для архівації, дата закінчення терміну дії може бути хороший вибір розділів. Але немає нічого, що означає, що може бути частиною ключа. Розмежування - це функція низького рівня, яка є досить загальною, і тут є принаймні дві чіткі та суперечливі моделі використання, обидві з яких мають законні найкращі практики.

— Кейд Ру

Він повинен бути частиною ключа кандидата, якщо не частиною самого первинного ключа. Ідея полягає в тому, що ваш розділ повинен узгоджуватися з первинним ключем.

Отже, відповідь - так, бажано бути частиною ПК. Якщо не інший ключ, який однаково хороший, щоб бути ПК.

— srini.venigalla
джерело

Ніколи не чув про кандидата ключ. Як можна вказати його в операторі Створити / Змінити таблицю?

— AngryHacker

Ключ кандидата - це лише ще один ключ, який може бути первинним ключем. Наприклад, ID - це первинний ключ. Але в тій же таблиці, якщо інший стовпчик для напр. PERSON_ID також може однозначно ідентифікувати рядок, який називається Candidate Key. 2-й і 3-й правила нормалізації також повинні відповідати всім ключам-кандидатам.

— srini.venigalla

Зрозумів. А як щодо 2-ї частини мого запитання?

— AngryHacker

Те саме, що і будь-який інший показник. приклад: СТВОРИТИ ІНДЕКС IX_ProductVendor_VendorID ON Purchasing.ProductVendor (BusinessEntityID);

— srini.venigalla

Це абсолютно неправильно. Ви можете розділити на багато полів, які взагалі не пов’язані з ПК OrderDate. Чи є у вас що-небудь для підтвердження своїх вимог?

— JNK