Первичный ключ в таблице

#sql-server #database-design #composite-primary-key

#sql-сервер #база данных-дизайн #составной первичный ключ

Вопрос:

У меня есть таблица table с featureid, ParameterID,MeasurementDateTime, значение параметра никогда не будет дублироваться, поэтому у нас есть составной ключ featureid, ParameterID,MeasurementDateTime. Данные выглядят следующим образом

  FeatureID  ParameterID MeasurementDateTime ParameterValue
   ASt-1    AP1         1/1/2009 0:00   0.00866667
   ASt-1    AP1         1/1/2009 1:00   0.00608333
   ASt-1    AP1         1/1/2009 2:00   0.016
   ASt-1    AP2         1/1/2009 3:00   0.01091667
   ASt-1    AP2         1/1/2009 4:00   0.01333333
   ASt-1    AP2         1/1/2009 5:00   0.01091667
   ASt-1    AP2         1/1/2009 6:00   0.0195
   ASt-2    AP1         1/1/2009 7:00   0.00733333
   ASt-2    AP1         1/1/2009 8:00   0.02075
   ASt-2    AP1         1/1/2009 9:00   0.00966666
   ASt-2    AP2         1/1/2009 10:00  0.01208333
   ASt-2    AP2         1/1/2009 11:00  0.00966667
   ASt-2    AP2         1/1/2009 12:00  0.01466667
   ASt-2    AP3         1/1/2009 13:00  0.02041666
   ASt-3    AP1         1/1/2009 14:00  0.01233333
   ASt-3    AP1         1/1/2009 15:00  0.0265
   ASt-3    AP1         1/1/2009 16:00  0.011
   ASt-3    AP1         1/1/2009 17:00  0.01383333
   ASt-3    AP2         1/1/2009 18:00  0.0135
   ASt-3    AP3         1/1/2009 19:00  0.009
  

Предложение where в большинстве запросов будет.

  1. featureid,ParameterID,year(MeasurementDateTime) 
 2. featureid,ParameterID,year(MeasurementDateTime) and month(MeasurementDateTime)
 3. featureid,ParameterID
  

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

Вопрос 1: Это нормально для наших данных или мы должны создать другой некластеризованный индекс для featureid, ParameterID?

Вопрос 2. Нужно ли нам периодически переиндексировать наши данные?

Комментарии:

1. 1) Вашего индекса кластеризации достаточно, хотя вы можете захотеть изменить его на идентификатор функции, идентификатор параметра, дату измерения по убыванию. Таким образом, более свежие измерения будут отображаться первыми в ваших запросах. 2) Если под переиндексацией вы подразумеваете удаление индексов и перестроение индексов, тогда да.

2. Что касается вашего предложения query WHERE , избегайте применения функций YEAR и MONTH к MeasurementDateTime столбцу, поскольку выражение не является саргируемым. Вместо этого учитывайте и включающую начальную дату и исключающую конечную дату, например MeasurementDateTime >= @FirstDayOfPeriod AND MeasurementDateTime < @FirstDayOfFollowingPeriod .

3. Чтобы обосновать ваш первичный / возможный ключ, вы имеете в виду, что featureid, ParameterID, MeasurementDateTime никогда не дублируются, но featureid, ParameterID, MeasurementDateTime, ParameterValue могут быть; и вам также нужно, чтобы все меньшие подстроки featureid, ParameterID, MeasurementDateTime тоже могли дублироваться.