Система сбора и обработки данных, Как лучше реализовать структуру Опции

[Litkevich Yuriy]

с лета никак не определюсь как должна быть устроена система.
Итак, есть море оборудования, на них датчики. С датчиков собирается информация и акумулируется в БД (FireBird). На клиентских машинах (их может быть очень много) стоит прога (назовем её клиент). С клиента всю ситему можно настривать (какие датчики опрашивать, параметры оборудования задавать и т.п.), и получать отчеты о работе оборудования (т.е. история изменения параметров, история показаний датчиков).
Отчеты в общем случае одинаковые, то есть почасовое состояние оборудования (например, сигналов с датчиков), но формулы расчета разные зависят от типа датчиков и оборудования.

Текущая структура выглядит так:

Хочется сделать так, чтобы пользователь мог в водить формулы расчета для заданного параметра. Но пока они жестко зашиты и вся обработка данных (разные расчеты, подготовка промежуточных результатов для отчетов) ведется в нутри БД с помощью тригеров, а при запросе с клиента еще и ХП'шки подключаются к этому процессу, досчитывая/выбирая необходимые данные. последний факт приводит к тормозам на стороне клиента.
Собирать отчетные данные помере сбора данных годится только для данной конкретной обстановке (определяемой настройками оборудования).

Вот я думаю заменить на этой схеме желтый квадратик
либо на приложение, которое будет принимать события от БД (уведомления) заниматся расчетами и складывать в некую выходную таблицу,
либо на UDF'ку, которая будет вызыватся тригером делать расчет, а тригер будет помещать результат в некую выходную таблицу.
Т.е. вынести прикладную часть (т.н. бизнес логику)

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

[Litkevich Yuriy]

А ввод формулу расчета юзером - фактически это заставление юзера программить, ведь это получается чтото типа запроса

несовсем так. Положим в вели еще Т.У. подключили физически. Юзер, в данном случае инженер заказчика, в водит формулу типа:
физТУ = К1ТУ*счетчикТУ

где:
физТУ - физическое значение Т.У.
счетчикТУ - значение счетчика данной Т.У. принятое из оборудования
К1ТУ - некий параметр пересчета который берется из сво-ств Т.У.

и далее пользователи (уже не только инженер) видят понятные для них цифры (литры, килограммы, кВт*ч и т.п.).
пока оперируем только примитивными расчетами и внутри БД. Но будут нужны и более серьезные, в том числе интегрирование и диференцирование.

Мне хочется понять 2 вещи
1) писать ли UDF, которая и распарсит формулу и посчитает, и использовать ее в нутри БД
или собственное приложение, которое будет работать по событиям из БД.
2) проводить расчет помере поступления данных и складывать в доптаблицу (при этом в базе появляются дополнительные данные) или
проводит расчет по запросу пользователя (т.е. формировать отчет ).

Есть такой нюанс. Данные нужно хранить 5 лет. Т.е. их будет много. Наша старая система №1 (Железо + ПК с Paradox'ом) обслуживает свыше 700 Т.У. Ситсема №2 (Железо + ПК с FireBird'ом) около 80 Т.У. И первая задача заместить старую систему №1, затем №2 (т.е. они буду единым целым), а затем наращивать кол-во Т.У. (~ до 2500 Т.У.)