Лучший способ хранить реальные события в БД?

Question

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

Упрощенный пример: есть обогреватель, который включается и выключается, и я получаю уведомление, когда это происходит. Мне нужно записать это, и на основе этих данных я смогу ответить на такие вопросы, как «Сколько времени нагреватель работал в прошлом месяце?»

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

Однако мне кажется, что для этого потребуется довольно много дополнительной обработки, например, чтобы ответить на приведенный выше пример вопроса. Я не вижу способа извлечь такой ответ только с помощью SQL.

Вопрос: есть ли более подходящий, более эффективный «шаблон хранения», чем то, что я здесь описываю?

Спасибо.

Answer 1

Вы можете хранить время включения нагревателя, а не отдельные события включения / выключения. Используйте столбцы time_on и time_off, чтобы отслеживать, когда нагреватель был включен и выключен соответственно, а затем вычтите time_on из time_off, чтобы получить длительность.

Когда обогреватель включен:

insert into heater_usage (time_on, time_off) values (now(), null);

Когда обогреватель выключен:

update heater_usage set time_off = now() where time_off is null;

Используйте уникальные ограничения, чтобы гарантировать, что никакие две строки не могут иметь null для time_off, в качестве базовой проверки, чтобы убедиться, что вы не оставляете "висячие" записи без time_off, если ваш скрипт не вызван должным образом , Вы можете проверить их при включенном обогревателе и удалить их.

Для суммирования общего времени:

select sum(time_off - time_on) from heater_usage;

Answer 2

Я не думаю, что вы предоставили достаточно информации, чтобы предложить проект.

Я уверен, что вы храните более одного типа событий;Это несколько или очень большое количество.

Насколько различны данные, которые необходимо хранить для каждого типа события?

Как часто нужно будет менять эту систему?Вам придется регулярно или редко редактировать или добавлять типы событий?

это система, которая должна быть гибкой в ​​отношении типа данных, которые генерирует событие?

, что говорит о том, что у вас фактически естьдва основных типа возможностей проектирования:

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

первая менее гибкая, вторая требует большей постобработки.