Кот Матроскин,

1. Тут, конечно, не нужно дерево, его надо транзитивно замкнуть - т.е. если параметр A зависит от B, а B зависит от С - надо держать в базе "А зависит от B", "А зависит от C", "B зависит от C".
У меня здесь работает рекурсия и я не чувствовал проблемы, но Вы правы, этот момент может стать предметом оптимизации.
Зависимости параметров - это практически статические данные, неважно сколько они занимают места и как тяжело обновляются. Здесь все не так просто. В описании зависимости показателей участвует переменная величина - время.
Двухчасовая добыча НСЖ на 18 час зависит от остатков НСЖ на 18 часов и на 16 часов(входящий остаток).
И так для каждой двухчасовки, сегодня, завтра и т.д.
Один из вариантов нашей диспетчерской системы (ССОНИ - Система сбора и обработки нефтепромысловой информации), каждые новые сутки начинал с генерации таблицы зависимости показателей на новые сутки, для всех объектов, показателей и конкретных временных параметров (ччддммгггг).
2. Проверять надо не все 1601 исходных показателя, а искать хотя бы один out-of-date. Учитывая пункт 1, это делается одним запросом с хорошим планом независимо от того, сколько и каких зависимостей мы проверяем.
Учитывая ответ на п.1... Нужна хорошо подготовленная таблица зависимостей. У меня нет таблицы зависимостей в чистом виде.
Расчетный показатель ставится в очередь расчета по сути триггером "after save" исходного показателя.
В триггере работает функция
AddQueue(idObject, idMessage, CurrentDate)
AddQueue(idObject, idMessage, CurrentDate-2) и т.д.
А при чтении показателя проверяется, если он в очереди расчета - рассчитываем, если нет - берем из базы.
3. Главное - это схема масштабируема. Если отчеты начинают тормозить - можно запустить какие-то фоновые задания на пересчет параметров в оффлайне, при наличии желания/бабла - на отдельных серверах и т.п. При этом отчеты переделывать не нужно вообще - если отчету повезло и фоновый процесс успел пересчитать все зависимости - ok, функция isObsolete покажет ему false и он быстро отдаст параметр пользователю, если не повезет - функция покажет True и придется считать самим.
Если же Ваша система упрется в пиковую длительность транзакции при закачке параметров (а пересчет пусть 7 показателей вместо одного тупого insert может поднять эту длительность в десятки раз )- это все, алес, никакой докупкой оборудования это не решить, систему надо выкидывать и проектировать заново.
Я вполне Вам верю, что для Вашей системы это некритично - но мы же обсуждаем не частный случай, а "систему для хранения параметров" вообще.
Вы на удивление "в теме". Сталкивались с аналогичными системами?
Фоновый процесс использовался в ССОНИ, и скорее всего будет использоваться в моей реализации. Очередь расчета предусмотрена.
Поставить в очередь расчета 7 показателей намного быстрее, чем пересчет 7-и показателей.
из статьиЗагрузка 1200 исходных показателей (2040 расчетных показателей ставятся в очередь расчета) занимает 0,3сек.Такая скорость записи позволит принимать много данных, но предел, все равно будет.
"Систему для хранения параметров" вообще, имхо, придумать невозможно.
При любой скорости загрузки данных, всегда найдется задача, для которой надо больше-быстрее-сложнее.
Для нее надо будет придумать свой вариант реализации.

baracs
DirksDR1.EAV может прилично работать на приличных объемах.Почему же незаурядным разработчикам, на флагмане СУБД, за несколько лет не удалось этого добиться (по вашим словам)?Не берусь судить.
А так, топик надо было создавать в "Сравнении СУБД". Или "Разработка информационных систем"
В этом форуме много авторов, чье мнение меня интересует.

softwarerDimitry SibiryakovРазве соотношение эффективности индексного доступа по сравнению с полным сканированием таблицы не зависит от селективности индекса
Оно зависит в том числе от селективности индекса, но далеко не только.
А можно еще таблицу значений задублировать:
ValTab1( date,idMessage,idObject, value)
и
ValTab2( idObject,idMessage,date, value)
таблицы кластерные в порядке выделенных ключевых полей.
Для двухчасовой сводки используем первую таблицу.
Для формирования трендов по атрибутам конкретного объекта - вторую.

Бредятина,

Модель непонятна((
Жаль, я старался...
Предположим "показатель" (неудачный термин - см. модель показателя в ЕМИСС) A исходный, а показатель B - зависимый.
B=A/2
Получено значение A=100 в 10:25.
Значит ли это, что значение B будет равно 50 тоже на 10:25?
И это выполняется для всех зависимых показателей?
Здесь дополнительные заморочки. Показатели кроме прочего подразделяются на:
- непериодические (например, 10:25)
- 2-х часовые (значение относится на границу четного часа; 2:00, 16:00 и т.п.)
- суточные ( значение за сутки;на 0:00 следующих суток, в УСОИ на 23:59:59 текущих суток)
- месячные и т.д.
Если показатель А непериодический, а В - 2-х часовой, то для В время округляется, либо до 10:00, либо до 12:00, в зависимости от требований.
Управляется это формулой расчета показателя В, обычно используется функция "взять последнее значение показателя".
Например, если уровень в емкости не менялся несколько дней, можно использовать последнее значение уровня.