а для меня-то в этом нет никакой разницы

или ты имеешь в виду, что запустить можно на некой соседней машине?

Немного непонятно, результаты расчётов нужно хранить или только в отчётах показывать/печатать?
Если хранить, то что делать при изменении формул?
Если только показывать/печатать, то зачем сервер напрягать?

Ну и для языка я бы в любом случае посоветовал бы что-нибудь высокоуровневое - Python например.
У него и библиотек много (есть оптимизированные для научных расчётов) и изучение быстрое.
Можно JavaScript подцепить - но он тормознее выйдет, и с библиотеками придётся повозится...

расчеты только для отчетов.

чтобы отчет махом показывался пользователю

я над этим тоже пока голову ломаю. Дело в том что формулы содержат параметры, а они могут менятся. Например кол-во импульсов на кВт*ч для эл.счетчика. однако счетчики иногда выходят из строя и надо ставить новый. Тогда нужно забить новое начальное показание счетчика и его коэффициент. я это дело думаю в историю записывать. А пока делаю так:
значения (целочисленный счетчик) пишу в таблицу с данными и штам времени. Затем с помощью ХП беру коэффициент счетчика из таблицы параметров оборудования считаю кВт*ч и пишу полученное значение в доптаблицу+ID данных которым это значение соответствует.

Мне кажется, ты таки зря всё это в сервер пихаешь.
Напиши себе наследника TableModel, который эти преобразования делает налету и будет тебе щастье.
Даже если для преобразования будешь использовать какой-нибудь скриптовый движёк тормоза будут заметны только на довольно больших объёмах данных.
Кстати, какие предполагаются объёмы отчётов? Какое количество инфы будешь показывать?

П.С У меня знакомый делал прогу на VB для обработки и графического отображения некоторых данных.
Данные были табличные, в простом текстовом формате по 15мб на файлик.
Перед отображением данные обрабатывались пользовательскими скриптами на VBS - скриптовый движёк встроенный в винду.
Задержек в отображении не было, хотя масштаб можно было выбирать.
Прога разрабатывалась 10-13 лет назад для стандартных на те времена машин.

Сообщение отредактировал Tonal - 26.12.2008, 8:29

сейчас самая потребная форма отчета такая:

Число | 00:00 | 01:00 | ... | 23:00 | Итог

т.е. для каждой Т.У. таблица по-часовой статистики за месяц.

каждая строка отрачает одини сутки и итог по суткам

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

Т.е для месяца <800 значений. Нужно очень постараться, чтобы на таких объёмах отчёты тормозили.
Хотя, конечно нет предела совершенству

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

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

в том числе, но и проц может быть многоядерным
этож просто параметры

что значит над базой?

я использую вариант который привел в теме FireBird: как преобразовать строки в столбцы?

ну и что, их можно рассматривать как теже оперативные данные, только меняются с другой скоростью (не синхронно)

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

Это значит некоторый свой, по возможности, независимый от Qt набор классов и контейнеров для нужных тебе данных и преобразований над ними.
Делается GUI, который всё это добро отображает.
Далее, делается связь этого добра с базой и/или непосредственно с прибором, чтобы можно было загружать данные.

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

П.С. Кстати, этот слой и называют "слоем прикладной логики" или "бизнес логики".

Сообщение отредактировал Tonal - 27.12.2008, 7:36