Правильное использование первичного ключа с метками времени

Question

У меня есть таблица, в которой хранятся записи с метками времени из набора датчиков, эти показания снимаются 14400 раз в день. (каждые 6 секунд).

Имеется 4 датчика, и они имеют общую таблицу данных.

На данный момент схема выглядит следующим образом:

id (int-PK)
time (DateTime)
sensor (int)
reading (int)

Это прекрасно работает, и у меня установлен первичный ключ на автоинкремент.

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

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

Это кажется беспроигрышным, но я хотел посмотреть, каковы будут последствия этого подхода.

Answer 1

Следует избегать составных индексов, особенно составных первичных ключей. Индекс шире, и это плохо влияет на производительность (и использование памяти). По моему личному мнению, плохой дизайн - иметь составной первичный ключ, поскольку более уникального единственного способа ссылки на ваш ряд не существует.

Мой совет - придерживаться дизайна, который у вас сейчас есть.

Answer 2

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

, если вы хотите сэкономить место, добавьте крошечный int для столбца sensor (у вас есть только 4 различных значения).Возможно, что-то меньше для reading, я сомневаюсь, что сенсор может записать 2 триллиона различных значений, которые может хранить int, скорее всего, вы можете использовать для него smallint или small int.

bigint   8 bytes, -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
int      4 Bytes              -2,147,483,648 to             2,147,483,647
smallint 2 Bytes                     -32,768 to                    32,767
tinyint  1 byte                            0 to                       255

Answer 3

В настоящее время вы используете суррогатный ключ . И вы собираетесь перейти к естественным ключам .

Работа с суррогатными ключами имеет преимущества перед естественными ключами, о которых вы можете узнать в предыдущей ссылке:

1. Неизменность
2. Изменение требований
3. Производительность
4. Совместимость
5. Однородность

(из википедии)

Вы можете искать другие сообщения о суррогатном против. естественные ключи в stackoverflow.

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

Answer 4

Использование комбинированного первичного ключа (или уникального индекса) в строках 10M может легко поглотить любое пространство памяти, полученное при удалении int PK (и более). Кроме того, ссылаться на строку из этой таблицы стало бы намного сложнее.

Я всегда держу int (или bigint, если требуется) PK на любом столе. Место для хранения, как правило, относительно мало по сравнению с остальными данными, а наличие простого способа связывать / ссылаться на строки всегда на месте делает жизнь WRT намного проще для улучшений и изменений в вашей модели данных.