Первичный ключ SQL Server на поле даты и времени
Я составляю новую таблицу в SQL Server 2005, которому нужны 2 поля: DateTime и MyValue (Int32). Поле DateTime будет уникально, таким образом, я буду устанавливать ограничение на уникальность данных на него.
Какая структура таблицы лучше и почему?
MyIndex (PK, интервал)
MyDate (дата и время) (IX_UniqueKey)
MyValue (интервал)
или
MyDate (PK, дата и время)
MyValue (интервал)
Мое чувство состоит в том, что я не хочу искусственный PK (MyIndex) в этой таблице, потому что это является ненужным и потому что даты будут уникальны, я буду использовать их для доступа к любой записи. Однако может случиться так, что это более производительно, чтобы иметь искусственный PK...?
4 ответа
Когда вы говорите, что даты будут уникальными, вы имеете в виду, что вы думаете, что они будут уникальными, или их уникальность гарантируется постановкой задачи? По моему опыту, некоторые вещи оказываются гораздо менее уникальными, чем можно себе представить (в качестве примера можно привести номера социального страхования США).
Если уникальность значений дат не гарантирована, следует добавить целочисленный ключ.
Если значения даты гарантированно уникальны, меняются ли они? Если они меняются, ссылаются ли на них другие таблицы? Если оба ответа "да", вам, вероятно, следует добавить целочисленный ключ.
Если значения даты гарантированно уникальны, не меняются и на них нет ссылок, вы можете использовать их в качестве ключа. Обычные DATETIME имеют размер 8 байт, а стандартные INTEGER - 4 байта, что может незначительно повлиять на индексацию. Если ваши значения даты - это просто даты, или только точные до минуты или меньше, и в более ограниченном диапазоне, разрешенном типом, вы можете использовать SMALLDATETIME и получить эти значения индекса до 4 байт.
Нет, ваша интуиция верна. До тех пор, пока никто не может скрыть от вас два (или, я полагаю, больше) одновременных события, учитывая доступное разрешение вашего процесса сбора данных, вы - здоровяк.
Если у вас есть гарантия, что время всегда будет уникальным (подумайте о разрешении компонента времени), то создание первичного ключа в столбце datetime - хороший выбор.
Если вы собираетесь вставлять только увеличивающееся время, тогда создание кластерного индекса в столбце первичного ключа также является хорошим выбором.
Если значение 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 не предоставляется базой данных - нет, не идеально. Дата-время из чего-либо, кроме базы данных, не может быть гарантированно точным на основе вставки.