Задача: есть продавец. Надо на графике (разбитый на 12 временных отрезков) отобразить сумму его продаж в каждом отрезке, ну и соответственно построить кривую графика.
Теперь камни. Общий временной интервал может быть любым, от 10 дней до года. Продажи раскиданы абы как. В день может быть десяток, и в следующий месяц 0.
Поэтому вопрос больше по логике решения, как правильно организовать ?
Скажем задали интервал в 60 дней. 60/12=5 , т.е. 5 дней в временном отрезке. Из базы вытягиваем сумму продаж за этот отрезок, сохраням как первый интервал. И так далее до 12 с каждым отрезком . Потом уже полученные данные отдаем в отрисовку графика.
Или есть более изящные решения ?
Полная версия: Создать график по данным.
Дорвей какой то по ссылке, все перелинковано и ничего полезного.
Построить сам график проблем не вызывает, для его построения софта куча. Вопрос именно по разделению на равномерное число интервалов и суммирования значений точек в нем.
Построить сам график проблем не вызывает, для его построения софта куча. Вопрос именно по разделению на равномерное число интервалов и суммирования значений точек в нем.
mathprolib обычно справляется с этим. и там код есть в тексте
VadimKЕсли база SQL, то можно и одним запросом все выбирать, в GROUP BY вполне можно вставить выражение вычисляющее (дата)->(номер интервала)
Скажем задали интервал в 60 дней. 60/12=5 , т.е. 5 дней в временном отрезке. Из базы вытягиваем сумму продаж за этот отрезок, сохраням как первый интервал. И так далее до 12 с каждым отрезком . Потом уже полученные данные отдаем в отрисовку графика.
Или есть более изящные решения ?
Если база SQL, то можно и одним запросом все выбирать, в GROUP BY вполне можно вставить выражение вычисляющее (дата)->(номер интервала)Не получается к сожалению, интервалы разные, приходится создавать на каждый интервал отдельный запрос.
Сейчас у себя грубо говоря решил так:
- начальная и конечная даты загнаны в timestamp
- разбиваем период по таймстампу на периоды
- делаем выборку в нужном периоде.
В принципе все работает, считает. Но получил пару “фи”, мол вместо ORM используются прямые запросы в базу. Плюс для облегчения использовал view в базе, что для django программеров вообще двоякое впечатление производит, мол не правильно все это.
А ты им явное , лучше неявного 
А ты спроси у тех кто говорит “фи”, как бы они решили эту задачу. И если для этого придётся городить 2-3 класса, то может они просто хотят использовать их по чаще?
А ты спроси у тех кто говорит “фи”, как бы они решили эту задачу. И если для этого придётся городить 2-3 класса, то может они просто хотят использовать их по чаще?