Блог

Для справки: недавно меня наняли инженером по базам данных в компанию по очистке воды. Мы устанавливаем машины для очистки воды на объектах по всей стране, и машины обрабатывают воду и отправляют нам непрерывные данные о состоянии поступающей воды (расход, температура, концентрация Х в поступающей воде и т.д.), А также о процедурах, которые машина применяла к этой воде в данный момент в время. Со временем объекты (и их различные компоненты) сильно меняются: машина может выйти из строя и ее необходимо заменить, для заполнения резервуаров машины может использоваться другая концентрация химического вещества, его расходомеры и другие датчики могут быть откалиброваны или настроены на другой масштаб, его химические насосы могут быть неисправны.заменено, и так далее и тому подобное. Это влияет на интерпретацию данных: например, если во входящую воду 01/01/2021 12:00:05 было добавлено 5 мл хлора, это означает две совершенно разные вещи, если концентрация хлора составляла 5% или 40%. концентрированный.

Точки данных очистки воды идентифицируются с помощью составного ключа, состоящего из идентификатора объекта и метки времени. Это было бы легко, если бы единственными данными, которые имели значение, были текущие данные, поскольку я мог бы просто сохранить параметры конфигурации на уровне сайта и извлекать их для точек данных по мере необходимости. Но нам нужно уметь правильно интерпретировать старые данные. Итак, я подумал о сохранении конфигураций в другой таблице, отслеживая все настройки для каждого сайта за каждый период времени, но невозможно создать внешний ключ между непрерывными временными метками точек данных и датами начала / окончания конфигураций — ближайшей вещью была бы какая-то проверка диапазона, например, «Точка данных.ВремЕнная метка МЕЖДУ конфигурациями.Запуск И настройка.Завершение». Таким образом, единственный другой вариант, который я вижу, — это хранить все настройки конфигурации для каждой точки данных рядом с каждой точкой данных, но это кажется ужасным решением, учитывая, сколько существует настроек конфигурации и сколько генерируется точек данных, тем более что большинство настроек даже не часто меняются.

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

Если я понял ваш запрос :

1 — точка данных воды идентифицируется составным ключом, состоящим из идентификатора сайта и метки времени :

• SiteID
• TimeStampID

2 . точка данных воды может иметь несколько конфигураций, например, при сбое :

• ConfigurationID
• Дата начала
• Дата окончания

Давайте рассмотрим DataPoint наличие следующей информации за конкретный день :

    DataPoint SiteID TimeStampID
   1001      101    01-02-2021 09:00:01
   1001      101    01-02-2021 10:20:31
   1001      101    01-02-2021 17:45:00
 

В тот день прорыв начался в 11:01:20 и закончился в 11:34:22.

 ConfigurationID DataPoint StartDate           EndDate
155             1001      01-02-2021 11:01:20 01-02-2021 11:34:22 
 

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

Я собираюсь создать таблицу конфигурации для хранения настроек в следующем формате:

 _SiteID_  _Start_                _End_                  <various settings fields>
318       "2021-01-01 12:22:03"  "2021-02-10 09:08:26"  ...
 

Где находится первичный ключ (SiteID, Start, End) . SiteID является внешним ключом для целого ID числа Site таблицы, Start является датой, с которой конфигурация начинает действовать, и End (по умолчанию: NULL ) является датой, с которой конфигурация больше не действительна. Чтобы все было хорошо и просто для пользователей (и для меня), а также для предотвращения любых случайных обновлений старых настроек конфигурации, когда вместо них должна была быть вставлена новая строка конфигурации, я собираюсь запретить UPDATE DELETE операции и над таблицей конфигурации для всех пользователей, кроме root, и вместо этого создать хранимую процедурудля «обновления» заданной конфигурации Site . Хранимая процедура примет любые новые параметры, указанные пользователем, скопирует любые параметры, которые пользователь НЕ указал, из самой последней конфигурации для этого сайта (т. Е. Строки с той же SiteID и NULL конечной датой), перезапишет дату самой последней строки конфигурации NULL End Start на дату для новой строкии, наконец, создайте новую строку с указанной Start датой.

ПРИМЕЧАНИЕ: Start дата и End дата сохраняются для каждой конфигурации, потому что конфигурации не обязательно могут быть непрерывными, т. Е. Это не тот случай, когда «как только срок действия конфигурации истек, появляется другая конфигурация, которая запускается точно в то время, когда срок действия этой конфигурации истек», поскольку развертывание оборудования для очистки воды иногда требует больших затрат.промежутки между ними, если клиенту не нужны наши услуги в течение некоторого периода времени. Без сохранения End дат для конфигураций нам пришлось бы предположить, что каждая конфигурация сохраняется до начала следующей конфигурации или до настоящего времени, если более поздняя конфигурация не сохранена. Таким End образом, дата сохраняется, чтобы мы никогда не думали, что «Сайт A был настроен на настройки X Y Z с января 2020 года по июнь 2021 года», когда на сайте A с мая 2020 года даже не было компьютера. Сохранение End даты явно рядом с Start датой также позволяет избежать неудобства, связанного с необходимостью полагаться на значения в других строках конфигурационных данных, чтобы знать, как интерпретировать данную строку конфигурационных данных.

Спасибо тому, кто изначально вдохновил меня на этот ответ, я понятия не имею, почему ваш ответ был удален.