Ключ раздела также должен быть частью первичного ключа?

24

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

  1. Должен ли столбец раздела быть частью основного? Рекомендуется так или иначе?
  2. Нужно ли создавать индекс для ключа раздела, или СУБД выполняет это самостоятельно?
sql-server sql-server-2008 sql-server-2008-r2 partitioning AngryHacker
источник

Ответы:

11

Не за что.

Один из наиболее распространенных сценариев разделения - использовать поле даты, которое совершенно не связано с вашим ПК.

Например, если у вас есть таблица Ordersс полем, OrderDateвы, скорее всего, разделите ее на месяц и год OrderDate.

Когда записи устаревают и перестают быть актуальными, вы можете переместить эти разделы в архивную таблицу или базу данных, чтобы они больше не обрабатывались.

Секционирование будет работать практически с любым полем, но для того, чтобы оно работало ХОРОШО, поля, на которые вы разбиваете раздел, должны использоваться в большинстве, если не во всех ваших запросах. Если вы не включите ключи разделов, то, по сути, вы получите дорогостоящее сканирование таблиц, которое выполняется по нескольким таблицам (разделам).

РЕДАКТИРОВАТЬ

Для части 2, я думаю, что ответ "нет". Ключ раздела используется для определения того, в какой раздел помещать строку, но я не думаю, что индекс поддерживается. Там может быть статистика в бэк-энде, хотя.

JNK
источник
10
Я знаю, что это старо, но оно привело меня на неверный путь, поэтому я решил прокомментировать других. Столбец раздела должен находиться в первичном ключе, если вы хотите использовать возможности ПЕРЕКЛЮЧЕНИЯ функции раздела. Если его нет в первичном ключе, вы получите эту ошибку: Partition columns for a unique index must be a subset of the index key.
Vaccano
Я согласен с @Vaccano
Сан
3

В дополнение к ответу JNK вам, вероятно, следует прочитать эту статью, в которой обсуждается выравнивание разделов таблицы и разделов индекса.

Существует много типов сценариев, в которых схема разделения точно следует первому столбцу первичного ключа - например, в сценарии хранилища данных, где датой моментального снимка таблицы фактов обычно является столбец раздела, а также первый столбец первичного ключа.

Но в равной степени в средах OLTP, где PK является IDENTITY или другим суррогатным ключом, не имеет смысла использовать это для разделения, так как разбиение на произвольные числа обычно не очень полезно. В системах OLTP вы также склонны разбивать по дате больше всего (вероятно, не на ПК), но потенциально также на региональном уровне или с помощью какого-то организационного подразделения (возможно, на ПК, если вы не используете суррогат).

Но это не требование.

Кейд Ру
источник
Ну, много вещей не является обязательным требованием. Даже индексирование не является обязательным требованием! Для функционального смысла разбиение должно быть выполнено по главному столбцу ключа-кандидата. Иначе как архитектор приложения будет использовать таблицу?
srini.venigalla
@ srini.venigalla Это распространенный случай, но другой распространенный случай (в равной степени так?) - это разделение на что-то, что вообще не является частью первичного или потенциального ключа - поскольку разделение часто используется для архивирования, срок действия может быть хороший выбор разделов. Но нет ничего, что подразумевает, что это может быть частью ключа. Разделение - это низкоуровневая функция, которая является довольно общей, и здесь есть по крайней мере два различных и противоречивых шаблона использования, оба из которых имеют законные лучшие практики вокруг них.
Cade Roux
0

Он должен быть частью ключа-кандидата, если не частью самого первичного ключа. Идея в том, что ваше разбиение должно совпадать с первичным ключом.

Таким образом, ответ, да, предпочтительнее быть частью ПК. Если не другой ключ, который достаточно хорош, чтобы быть ПК.

srini.venigalla
источник
Никогда не слышал о ключе-кандидате. Как можно указать это в операторе создания / изменения таблицы?
AngryHacker
Ключ-кандидат - это еще один ключ, квалифицированный как первичный ключ. Например, ID является первичным ключом. Но в той же таблице, если другой столбец для, например. PERSON_ID также может однозначно идентифицировать строку, которая называется ключом-кандидатом. 2-е и 3-е правила нормализации также должны применяться ко всем ключам-кандидатам.
srini.venigalla
Понял. Как насчет 2-й части моего вопроса?
AngryHacker
То же, что и любой другой индекс. пример: CREATE INDEX IX_ProductVendor_VendorID ON Покупка.ProductVendor (BusinessEntityID);
srini.venigalla
4
Это абсолютно неверно. Вы можете разделить многие поля, которые вообще не связаны с PK, например OrderDate. У вас есть что-нибудь, чтобы подтвердить ваши претензии?
JNK