Комбинированный первичный ключ против одиночного целого первичного ключа большой таблицы

Question

У нас есть база данных, в которой хранятся большие объемы данных измерений следующим образом.

• Существует таблица под названием «Инструмент», где каждый интрумент имеет первичный ключ из трех столбцов [CustomerCode | LocationCode | InstrumentCode]. Колонки типа VARCHAR (4), поэтому полный первичный ключ выглядит как ABC | L001 | S001. Эти коды имеют смысл для нас, поэтому мы не можем просто изменить их для целых чисел. Другие отношения ar также определены на этих столбцах, но они не подходят для этого вопроса. В этой таблице содержится около 200 000 строк, представляющих различные точки данных измерений.
• Существует таблица под названием «InstrumentLoggings», где каждый InstrumentLogging имеет первичный ключ из четырех столбцов [CustomerCode | LocationCode | InstrumentCode | Отметка]. Столбец Timestamp имеет тип DateTime. Отношение внешних ключей определяется в первых трех столбцах таблицы «Инструмент». Затем есть пятое поле типа VARCHAR (25), содержащее значение для этой метки времени. В этих таблицах содержится около 5 миллиардов записей (это возмутительно или это совсем не плохо?).

Вот короткая схема текущей ситуации:

Наша проблема в том, что таблица InstumentLoggings растет над 200GB, и производительность начинает уменьшаться. Кроме того, резервное копирование и восстановление слишком трудоемки. Мы ищем способы устранить все эти поля первичных ключей в одном поле в таблице InstrumentLoggings.

Могу ли я просто добавить дополнительную таблицу InstrumentId на таблицу Instrument и создать таблицу InstrumentLoggings с тремя коллами [InstrumentId | Временная метка | Значение], где первичный ключ состоит из столбцов InstrumentId и Timestamp? Или лучше для производительности добавить дополнительный столбец InstrumentLoggingId к предыдущей идее?

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

Answer 1

Посмотрите Why use multiple columns as primary keys (composite primary key). Похоже, что существует консенсус в отношении того, что мы используем для новой разработки: первичный ключ единственного столбца, а затем уникальное ограничение, когда необходимо, на содержащем составной ключ.

Это был ваш вариант 2 с InstrumentLoggingId. При необходимости вы могли бы использовать уникальное ограничение или просто дополнительный указатель на InstrumentId/Timestamp.

EDIT

Обоснование этого выбора (на основе опыта, - я не обучен DBA :-)):

1. ORM простота и будущее корректуры. Если в бизнес-ключ добавлен новый столбец, любые таблицы ссылок не должны меняться, а изменения кода намного проще.
2. Уникальность и галстук. Предполагая, что вы идете с InstrumentId/Timestamp в качестве своего ПК, что вы делаете с летнего времени ... UTC, чтобы избежать дубликатов? Или ошибка на устройстве из-за конфликта PK и потери данных? Что произойдет, если одно из устройств совершит ошибку или неправильно синхронизируется с синхронизацией часов ... он может начать извергать повторяющиеся моменты.Наличие отдельного уникального ключа позволяет вам разобраться в том, что произошло дальше, будучи способным к последовательности по времени и к этому ключу и настраивать конкретные записи, которые вы хотите настроить, где могут быть дубликаты.
3. У меня была третья причина, но я не могу вспомнить, что это такое, если только оно не смешалось с номером 2. Будет ли позже редактировать, если я смогу запомнить :-)
4. Вставка производительности. AFAIK Создание вашей уникальной (вероятно, идентичной личности) кластера с кластеризацией ПК будет содержать записи, которые будут вставлены в конце, а не вставлять и перетасовывать физический порядок записей на основе бизнес-ключа (например, предполагая, что вы пошли с кластеризованным PK из InstrumentId/Timestamp, каждая вставка для Инструмент 1 будет физически вставлен перед записями для Инструмента 2). Я не понимаю, как это происходит, но я знаю, что накладные расходы больше, чем просто вставка.