Первичный ключ SQL Server в поле даты и времени

Question

Я создаю новую таблицу в SQL Server 2005, которая требует 2 поля: DateTime и MyValue (Int32). Поле DateTime будет уникальным, поэтому я буду устанавливать для него уникальное ограничение.

Какая структура таблицы лучше и почему?

MyIndex (PK, int)
MyDate (datetime) (IX_UniqueKey)
MyValue (int)

или

MyDate (PK, datetime)
MyValue (int)

Мне кажется, что я не хочу использовать искусственный PK (MyIndex) в этой таблице, потому что он не нужен, а даты будут уникальными, и я буду использовать их для доступа к любой записи. Тем не менее, возможно, что более искусно иметь искусственный ПК ...?

Answer 1

Когда вы говорите, что даты будут уникальными, вы имеете в виду, что думаете, они будут уникальными, или их уникальность гарантируется постановкой задачи? По моему опыту, некоторые вещи оказываются гораздо менее уникальными, чем можно себе представить (например, номера социального страхования США).

Если значения даты не гарантированно уникальны, следует добавить целочисленный ключ.

Если значения даты гарантированно уникальны, они меняются? Если они меняются, на них ссылаются другие таблицы? Если оба ответа «да», вам, вероятно, следует добавить целочисленную клавишу.

Если значения даты гарантированно уникальны и не изменяются или на них нет ссылок, вы можете использовать их для ключа. Обычные DATETIME - 8 байтов, а стандартные значения INTEGER - 4 байта, которые могут незначительно повлиять на индексирование. Если ваши значения даты являются просто датами или точными с точностью до минуты или менее и в более ограниченном диапазоне, разрешенном типом, вы можете использовать SMALLDATETIME и получить эти значения индекса до 4 байтов.

Answer 2

Если значение DATETIME будет заполнено IE базы данных:

INSERT INTO your_table
  (mydate, myvalue)
VALUES
  (GETDATE(), 1234)

... тогда да, создание столбца mydate в качестве первичного ключа является идеальным решением. Если дата предоставлена ​​приложением IE:

INSERT INTO your_table
  (mydate, myvalue)
VALUES
  (@my_date_value, 1234)

... при условии, что @my_date_value не предоставляется базой данных - нет, не идеально. Дата и время из чего-либо, кроме базы данных, не могут быть гарантированно точными на основе вставки.

Answer 3

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

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

Answer 4

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