Первичный ключ SQL Server в поле datetime

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

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

MyIndex (PK, int)
MyDate (datetime) (IX_UniqueKey)
Значения MyValue (инт)

или

MyDate (PK, datetime)
Значения MyValue (инт)

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

6
data-modeling database-design sql-server-2005

4 ответов

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

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

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

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

10

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

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

...тогда да, делая

2

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

1

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

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

1