Отчетность, которая плохо сводится к реляционным таблицам. Тут такое дело - промежуточные данные для отчетности идеально делаются sql запросами. Неважно, в 10 строк или в 100 - ключевой момент, что в схеме БД не создаются новые объекты для таких запросов (их очень неудобно поддерживать). Но постобработка - лучше это делать на clojure. Например, когда надо 150 кодов аналитики разложить по нетривиальным правилам в 30 пунктов итогового отчета. Я раньше это делал на императивных расширениях SQL - поддержка задалбывает (отладки нет, проверка ошибок через задницу, контроль версий аналогично). Далее - удобнее завернуть это дело в json на clojure и отдать клиенту (десктопному приложению и js-клиенту) чем отдавать нативным протоколом СУБД клиентской либе этой же СУБД.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2013-04-03 07:27 pm (UTC)Тут такое дело - промежуточные данные для отчетности идеально делаются sql запросами. Неважно, в 10 строк или в 100 - ключевой момент, что в схеме БД не создаются новые объекты для таких запросов (их очень неудобно поддерживать).
Но постобработка - лучше это делать на clojure. Например, когда надо 150 кодов аналитики разложить по нетривиальным правилам в 30 пунктов итогового отчета. Я раньше это делал на императивных расширениях SQL - поддержка задалбывает (отладки нет, проверка ошибок через задницу, контроль версий аналогично).
Далее - удобнее завернуть это дело в json на clojure и отдать клиенту (десктопному приложению и js-клиенту) чем отдавать нативным протоколом СУБД клиентской либе этой же СУБД.