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

[Litkevich Yuriy]

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

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

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

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

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

[kuler]

возможно такая вещь называется трехзвенная система (или многозвенная)

Но пока они жестко зашиты

зашиты в код ХрПр? ну дык можно либо параметрами передавать, либо считывать из какихто таблиц, а к таблицам интерфейс.

[AD]

Собственно говоря, система анализа послеполетной информации - основной проект которым я занимаюсь. Правда, в нем нет БД. Смысл такой. Данные с датчиков, принимаемые нашими приборами, пишутся на флеш-память в определенном виде (лог-файлы). Есть входные данные, согласно которым указывается какие параметры следует выбрать из лог-файлов.
На мой взгляд, твоя задумка заменить ХП на программу правильное. Возможно, следует дать пользователю возможность вводить в некотором формализованном виде формулу (если она не является чересчур громоздкой), а программа будет ее распарсивать и в соответствии с ней делать соответствующие расчеты. На первый взгляд, у меня такое мнение.
Посмотрел схему. Чем занимается scanner??? Это ПО или какое-то БД-шная штуковина?

[Litkevich Yuriy]

зашиты в код ХрПр?

да. Например для расчета потребления эл.энергии для заданной точки учета (далее Т.У.) из таблицы эл.счетчиков берется параметр счета (кол-во импульсов на кВт*ч) и считается кВт*ч. Для другого типа Т.У. свой расчет.

Чем занимается scanner???

софтина на Qt'ях опрашивающая через последовательный порт контроллеры расположенные в оборудовании и складывает информацию в БД.

сначало Scaner запрашивает у БД, что нужно опрашивать, вызовом процедуры P_GETDEVICE. Получает масив из трех столбцов:
PORT, ADDRESS, FIELD - Номер порта, адрес устройства в сети ModBus и номер поля данных
Опрашивает устройства по полученому списку, затем возвращает в БД данные с помощью ХП P_APPENDDATA(PORT, ADDRESS, FIELD, VALUE)
эта процедура складывает данные в табличку и еще завёт какую нибудь ХП для промежуточных расчетов (примитивных)

[AD]

Лучше все промежуточные расчеты вынести из СУБД в приложение. Если не ошибаюсь, ПО быстрее делает расчет, чем СУБД (если правильно сделать, конечно! )

[kuler]

да. Например для расчета потребления эл.энергии для заданной точки учета (далее Т.У.) из таблицы эл.счетчиков берется параметр счета (кол-во импульсов на кВт*ч) и считается кВт*ч. Для другого типа Т.У. свой расчет.

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

[Litkevich Yuriy]

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

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

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

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

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

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

[kuler]

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

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

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

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

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

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

[Litkevich Yuriy]

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

про новую пока затрудняюсь сказать, оставил на недельку работать (только две Т.У.) посмотрю потом

в старых больше трех месяцев данные не копятся иначе на выборку отчета от 30 до 40 мин уходило, но тачка медленная (селерон полуторный с 512метрами памяти)

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

а UDF тоже, этож просто dll'ка которую СУБД подгружает по мере надобности

[kuler]

(селерон полуторный с 512метрами памяти)

ну это вообще не серьезно

UDF тоже, этож просто dll'ка которую СУБД подгружает по мере надобности

дык он её юзает возможно в том же процессе