Дарю разработчикам идею по хранению трендов

[VADR]

Может быть, это уже используется у кого-то, но я не встречал.
Идея в следующем:
1. Создаём таблицу единиц измерений для хранимой величины. Одну из единиц измерения считаем основной (к примеру, ту, которая в СИ стандартная). В таблице прописываем все используемые единицы измерения для этого параметра и формулы перехода от них к основной и обратно. К примеру, для давления стандартной называем Па, и в таблице вводим МПа, кПа, кгс/см2, вплоть до фунтов силы на квадратные дюймы.
2. При создании тренда указываем тип параметра и единицу измерения, в которой приходят данные. Перед сохранением - по формуле из п.1. приводим к основной единице измерения и в этих единицах пишем.
3. При запросе данных указываем тип параметра и единицу измерения, в которой хотим получить данные. При чтении - читаем в основных единицах и по формуле из п.1 переводим в требуемые.
Что это даст:
1. При каких-то переделках технологии или управлении, если вдруг вздумается на каком-то параметре изменить единицы - старые накопленные данные не будут бесполезными и не будет необходимости учитывать то, что когда-то тут были Кельвины, а стали Фаренгейты.
2. Если на предприятии несколько объектов, на которых используются разные единицы измерения:
2.1. Проще делать дополнительные расчёты. Формулы забиваются также, исходя из основных единиц измерения, приведение к нужным производится автоматически.
2.2. Проще сводить балансы. Массовые расходы можно просто сложить, не заморачиваясь тем, что в одном месте килограммы в секунду, а в другом - тонны в час.
Как-то так.

ЗЫ: А если кто-нибудь из разработчиков применит и в ответ захочет подарить мне лицензию на такой продукт - совсем не откажусь :)

[Romcheg]

Чтобы зарабатывать на полезной модели - ее надо сначала запатентовать.
Вообще - идея хранения "сырых" данных в архивах не нова. Вот только многих разработчиков смущает именно необходимость преобразования данных перед их отображением, многие, стремясь к повышению скорости обработки, стараются как можно меньше промежуточных шагов делать между выборкой и ее отображением на графике.
По Вашим плюсам:
1) После переделки технологии и ухода на другие единицы - старые данные можно также преобразовать. Это делается 1 раз.
2.1) Именно благодаря понятию первичной обработки данных - переход на другой объект выполняется в проекте банальной сменой множителя, или формулы в настройках параметра.
2.2) Вот тут как-то не совсем понял: как можно сложить кг/с с т/час и не заметить разницы - разве балансы смогут сойтись, если параметры в разных единицах измерения будут? И какой вообще смысл в результате сложения абсолютно разномерных величин?

[izhidkov]

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

[VADR]

После переделки технологии и ухода на другие единицы - старые данные можно также преобразовать. Это делается 1 раз.

При этом остаётся старый тренд в старых единицах. Если придётся просматривать историю "до того, как" - как-то надо будет иметь в виду, что там надо делать пересчёт. Можно, конечно, скриптом базу обработать и привести к сегодняшним размерностям. А если данные уже не в базе, а в архиве, записаны на ленты и убраны в шкаф? Такие резервные копии тоже существуют и используются.

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

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

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

Передача параметров настраивается один раз, после чего одна система запрашивает данные в нужных её единицах, вторая - выдаёт в соответствии с требованиями. Если может :). Либо в запрашивающей системе настраивается то, в каких единицах данные придут. Опять же - настройка делается один раз.

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

В последнее время частенько встречал упоминания об использовании обычных реляционных баз данных для хранения трендов. Представляете, какой там объём пред- и постобработки, а также накладные расходы при выборке?

[SaNNy]

Хранить данные нужно всегда в одной единице измерения. А в какой единице измерения выводить тренд - решается при отображении пользователем. Это как-бы очевидные вещи.
Если это кому-то не очевидно, то о компетенции такого человека стоит задуматься.

[VADR]

Ну, я бы не стал говорить столь категорично. В любом случае - я предложил, а будет ли кто использовать - пусть сами решают, надо это или нет.

[krapsv]

В моей системе есть понятие "расчетных" каналов. Код расчета находится в DLL.
Глобальный подход таков, что много-много формул всевозможных расчетов оформляются в одну общую DLL. Под конкретный проект пишется небольшой файл, указывающий где находится сила тока, где расход и т.п. Тогда можно просто по ходу просмотра менять формулу и смотреть, что есть, и что было. При расчете также легко указать, что до определенного момента была одна формула, а после - другая.

Правда, у меня пока не строятся чисто расчетные графики. В планах такое есть.

И хоть немного другим путем, но имеем ли мы то, что вам нужно?