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

[Litkevich Yuriy]

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

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

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

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

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

[kuler]

проводить расчет помере поступления данных и складывать в доптаблицу (при этом в базе появляются дополнительные данные) или
проводит расчет по запросу пользователя (т.е. формировать отчет ).

это зависит от колва запросов одних и тех же данных. Если одни и теже данные нужны, не знаю, 100 раз то наверно лучше их один считать

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

с какой скоростью растет база?

1) писать ли UDF, которая и распарсит формулу и посчитает, и использовать ее в нутри БД
или собственное приложение, которое будет работать по событиям из БД.

с точки зрения кода наверно одно и тоже, но приложение можно запустить на другом компе или ядре, а udf врядли, то есть будет теоретически более производительно