Комментарии 16
Я похожую в чем-то штуку писал, только расчитанную на ежедневный оффлайн-просчет и отправку на почту большого количества датчиков (с возможностью пересчета в прошлое, аякс-валидацией SQL-запроса, простейшими графиками, тэгами и т.д.):
github.com/DmitryKoterov/dklab_dbstat
Все никак не доходят руки причесать и нормально опубликовать, но используется эта штука во многих проектах, не только моих.
github.com/DmitryKoterov/dklab_dbstat
Все никак не доходят руки причесать и нормально опубликовать, но используется эта штука во многих проектах, не только моих.
Так собирать sql-запросы при более-менее сложной логике будет не сильно приятно, а отлаживать тем более.
Мы используем инструкции with
Возможность вложеных запросов
мы еще не использовали на практике
(эта версия отчетов свежая).
Для этого можно выводить
на страницу отчета прошедший
через пре-процессор код запроса
(в посте это есть в самой последней картинке).
Есть предложения?
with t as (
-- select [[f.d_start]] as d_start from dual
select sysdate - 14 from dual
)
select.from table src
cross join t
Возможность вложеных запросов
мы еще не использовали на практике
(эта версия отчетов свежая).
Для этого можно выводить
на страницу отчета прошедший
через пре-процессор код запроса
(в посте это есть в самой последней картинке).
Есть предложения?
Вложенные запросы вынести — это хорошо, но приятнее писать и отлаживать не намного становится:)
В последнее время я перестал использовать монструозные запросы, обхожусь более менее простыми с обработкой в приложении. Да появляются запросы в цикле, да дольше выполняется, но зато не приходится копаться в четырехслойных запросах, как приходилось делать, когда я только пришел.
В последнее время я перестал использовать монструозные запросы, обхожусь более менее простыми с обработкой в приложении. Да появляются запросы в цикле, да дольше выполняется, но зато не приходится копаться в четырехслойных запросах, как приходилось делать, когда я только пришел.
Понятно,
у нас другая специфика.
Такой была первая версия на PHP.
Куча кода тогда накапливается там, и им сложно управлять,
а тут система заставляет придерживаться архитектуры,
то есть больше шансов на парное программирование
или доработку отчета не его автором.
Люди, которые на этом пишут,
не знают ничего, кроме sql.
Да и как-то лезть в код, перезапускать сервер
«не православно»
у нас другая специфика.
Такой была первая версия на PHP.
Куча кода тогда накапливается там, и им сложно управлять,
а тут система заставляет придерживаться архитектуры,
то есть больше шансов на парное программирование
или доработку отчета не его автором.
Люди, которые на этом пишут,
не знают ничего, кроме sql.
Да и как-то лезть в код, перезапускать сервер
«не православно»
Ну кучу кода же тоже можно систематизировать:) У нас родился фреймворк, который отвечает за отображение данных.
Каждый отчет — это набор из нескольких классов, чтобы создать отчет нужно определить фильтры/параметры, колонки (поддерживается иерархия), написать код для заполнения массива данных.
Дальше на основе этого фреймворк рисует отчет со всеми плюшками.
Соответственно все эти отчеты разбиты по группам, возможно настройка прав доступа пользователей к ним.
Каждый отчет — это набор из нескольких классов, чтобы создать отчет нужно определить фильтры/параметры, колонки (поддерживается иерархия), написать код для заполнения массива данных.
Дальше на основе этого фреймворк рисует отчет со всеми плюшками.
Соответственно все эти отчеты разбиты по группам, возможно настройка прав доступа пользователей к ним.
Расскажите пожалуйста, почему вы решили писать отчетник с нуля, а не воспользовались готовым решением?
Сложно ответить.
Хочется самому проектировать архитектуру, а не подстраиваться под существующие (наверное, это велосипед),
иметь возможность дописать любой функционал, который придет в голову (например, загрузку из Excel и построение отчета по загруженному)
Да и просто интересно написать что-то на python (этот язык просто затягивает).
Хочется самому проектировать архитектуру, а не подстраиваться под существующие (наверное, это велосипед),
иметь возможность дописать любой функционал, который придет в голову (например, загрузку из Excel и построение отчета по загруженному)
Да и просто интересно написать что-то на python (этот язык просто затягивает).
На PHP было куда проще разобраться, а вариант на Phyton от «сумасшедших гениев» не спасет. Он приносит еще больший технический долг для тех, кто будет все это сопровождать.
p.S. привет от бывшего подчиненного.
p.S. привет от бывшего подчиненного.
Как мне кажется, python намного проще понять из-за отсутствия этих разных значков $, скобок и прочего (глаза разбегаются).
Я обычный быдлокодер с очень поверхностными знаниями в нескольких языках и технологиях.
По поводу «технического долга», это способ поднять узнать что-то новое в новой области.
Им можно воспользоваться, а можно и нет.
Наверное, много велосипедов развелось в последнее время.
Есть из чего выбрать и с кем обменяться опытом.
Это же хорошо, а не плохо.
Ни в коем случае не вынуждаю знакомится с новыми языками.
Считаю своим долгом выложить свои наработки (пользуюсь OpenSource решениями).
Использовать их или нет, каждый решает сам для себя.
P.S.
Привет.
Я обычный быдлокодер с очень поверхностными знаниями в нескольких языках и технологиях.
По поводу «технического долга», это способ поднять узнать что-то новое в новой области.
Им можно воспользоваться, а можно и нет.
Наверное, много велосипедов развелось в последнее время.
Есть из чего выбрать и с кем обменяться опытом.
Это же хорошо, а не плохо.
Ни в коем случае не вынуждаю знакомится с новыми языками.
Считаю своим долгом выложить свои наработки (пользуюсь OpenSource решениями).
Использовать их или нет, каждый решает сам для себя.
P.S.
Привет.
Про подстроения — спорно, тем более в больших отчетниках банальные грабли уже убраны…
Второй аргумент более весомым выглядит ).
Второй аргумент более весомым выглядит ).
> Расскажите пожалуйста, почему вы решили писать отчетник с нуля, а не воспользовались готовым решением?
Кстати, вопрос насчет готовых решений: можете какое-нибудь посоветовать или хотя бы назвать парочку?
Кстати, вопрос насчет готовых решений: можете какое-нибудь посоветовать или хотя бы назвать парочку?
Из открытого работал с Jasper. О Pentaho неплохо отзывались.
В целом вот.
en.wikipedia.org/wiki/List_of_reporting_software
До странного неплохое впечатление произвел SSRS, но просто наверное удобство все писать в одной экосистеме сказалось…
В целом вот.
en.wikipedia.org/wiki/List_of_reporting_software
До странного неплохое впечатление произвел SSRS, но просто наверное удобство все писать в одной экосистеме сказалось…
Зачем вам понадобилось шаблонизировать sql запросы? Вы же понимаете, какое это опасное зло, верно?
Понимаю, что можно и в ногу выстрелить.
Но это просто инструмент. Им нужно пользоваться только тогда, когда это необходимо.
Мы им пользуемся очень редко, так как все разработчики (3 человека) достаточно хорошо знаем SQL.
Чтоб пояснить, что с помощью системы можно очень просто решать задачи, которые чистым SQL реализуются очень сложно,
приведу пример (реальный, между прочим)
В форме задать период и тип группировки (по неделям, месяцам, кварталам)
Получить много таблиц со столбцами периодов, попавших в отчетный с учетом типа группировки.
И детализация чтоб работала (можно щелкнуть на любой цифре и получить детальную информацию по объектам, которые использовались для расчета этой ячейки).
С помощью шаблонизатора решается достаточно просто:
— Сделать запрос, генерирующий поля: date_from, date_to, period_title
мы используем рекурсивные или иерархические (в зависимости от БД) запросы.
в этом запросе известны параметры фильтра и он один на все таблицы (многократное использование)
— Создать запрос типа
XML-настройки для табличного виджета со ссылками детализации генерируется так же.
Как бы, и все.
А теперь попробуйте это сделать как-то по другому, без использования шаблонной системы.
Резюмирую. Это просто инструмент.
Его, конечно, можно использовать не правильно.
Но это просто инструмент. Им нужно пользоваться только тогда, когда это необходимо.
Мы им пользуемся очень редко, так как все разработчики (3 человека) достаточно хорошо знаем SQL.
Чтоб пояснить, что с помощью системы можно очень просто решать задачи, которые чистым SQL реализуются очень сложно,
приведу пример (реальный, между прочим)
В форме задать период и тип группировки (по неделям, месяцам, кварталам)
Получить много таблиц со столбцами периодов, попавших в отчетный с учетом типа группировки.
И детализация чтоб работала (можно щелкнуть на любой цифре и получить детальную информацию по объектам, которые использовались для расчета этой ячейки).
С помощью шаблонизатора решается достаточно просто:
— Сделать запрос, генерирующий поля: date_from, date_to, period_title
мы используем рекурсивные или иерархические (в зависимости от БД) запросы.
в этом запросе известны параметры фильтра и он один на все таблицы (многократное использование)
— Создать запрос типа
select var_name
{% for field in datasets.field_generator %}
,
count(case
when period between to_date({{field.d_from}}, 'dd.mm.yyyy') and to_date({{field.d_from}}, 'dd.mm.yyyy')
then 1
end) as {{field.period_title}}
{% endfor %}
from table
where period between [[f.period.from]] and [[f.period.to]]
group by var_name
XML-настройки для табличного виджета со ссылками детализации генерируется так же.
Как бы, и все.
А теперь попробуйте это сделать как-то по другому, без использования шаблонной системы.
Резюмирую. Это просто инструмент.
Его, конечно, можно использовать не правильно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сервер отчетов на django