mikola1982Вот я и думаю правильный подход или надо тянуть милионы строк в приложение и там делать обработку.Правильно.

Ещё один подход - хранить в базе несколько вариантов данных для разных разрешений. А уже для данного сохранённого разрешения можно делать и пересчёт (возможно).

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

Известные системы типа всяких карт так и делают.

pirovindosЗависит от того, какие данные. Например, при простом прореживании, ты не отправишь из БД данные, которые больше всего интересуют пользователя. Какой-нибудь резкий всплеск. Решение нужно принимать исходя из прикладной задачи. Для чего график нужен пользователю?Тут же не вопрос об алгоритме прореживания, а о том, где его делать - на клиенте или сервере, и в какой момент - при сохранении данных в базу или при запросе информации.

А алгоритм, понятно, нужно выбирать в зависимости от задачи. Это уже второстепенная вещь, это и поменять легко можно.

pirovindosalexeyvg,

По-моему, прежде чем решать ГДЕ реализовывать, нужно решить ЧТО реализовывать.Считаю, это несвязанные вещи.

Где реализовывать алгоритм - это архитектура системы. Если она зависит от конкретного алгоритма прореживания, то это плохая архитектура.

Плохая архитектура - это значит, что при изменении требований (типа подошёл бизнес-юзер и сказал - а вот с нового года мы не будем показывать всплески, если они вылазят больше чем на 50 процентов от среднего), программисты начинают ныть - нуууу, это надо всё переписывать....

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

Вначале можно только определить базовые принципы - например, зависят ли алгоритмы от пользователя или они общие и т.п. - то, что влияет на архитектуру системы.
И то, хорошая архитектура позволит менять и такое, не выбрасывая то, что уже было сделано.

pirovindosЕсли еще актуально, то
1. "принятия срочных решений"
не нужно делать запросы к базе в 10000 точек. Все это должно быть автоматически в онлайне, подгружаться постепенно и показываться в режиме скользящего окна. (Детали опускаю).Понятно, что в режиме скользящего окна, ТС об этом писал. Он как раз спрашивал о деталях.