Для действительно сложных отчетов люди иногда пишут на своем языке, а не на языке sql?

Question

Мне нужно написать несколько довольно сложных отчетов. Некоторые из них ... Я не уверен, как написать SQL-запрос только для одного из значений, не говоря уже о том, чтобы объединить их в один запрос.

Является ли обычным делом просто взять дерьмовую загрузку данных и вычислить все это с помощью кода? Или я должен попытаться найти способ заставить все отчеты полагаться на sql?

У меня очень богатая модель предметной области. Фактически, части кода могут быть расширены для вычисления именно того, что они хотят. Фактическая логика не так сложна для написания - и лучше работать с моей моделью предметной области, чем с SQL. С SQL написание бизнес-логики, ее рефакторинг, тестирование и контроль версий - это настоящая боль, потому что она отделена от вашего реального кода.

Например, одна статистика, которую они хотят получить, это процент того, насколько они улучшились, особенно по отношению к другим людям в том же классе, в той же школе и по сравнению с другими школами. Это требует некоторого довольно подробного анализа того, как они работали в прошлом, с их последней информацией, а также вычисления для групп, с которыми вы сравниваете в целом. Я даже не представляю, как будет выглядеть SQL-запрос.

Дело в том, что это улучшение в% не является столбцом в базе данных - оно требует больших вычислений само по себе, анализируя все живые данные в режиме реального времени. Невозможно кэшировать эти данные в столбце, так как выполнение этих вычислений для каждой строки, которая необходима каждый раз, когда учащийся что-то делает, СУМАСШЕДО.

Я немного боюсь вытащить сотни и сотни записей, чтобы получить эти цифры. Возможно, мне придется вытащить это количество, чтобы вычислить 1 значение для 1 пользователя ... и если они хотят получить отчет для всех пользователей на одном экране, то в основном потребуется анализ всей базы данных. И это всего лишь 1 столбец значений многих столбцов, которые они хотят получить в отчете!

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

В любом случае, я хотел бы спросить вас, какие решения вы использовали для решения подобных проблем.

Answer 1

Иногда отчет может быть создан одним запросом. Иногда необходимо написать какой-то процедурный код. И иногда, даже если МОЖЕТ использоваться один запрос, гораздо лучше / быстрее / понятнее написать немного процедурного кода.

Показательный пример - другой разработчик на работе написал отчет, в котором использовался один запрос. Этот запрос был удивительным - он перевернул таблицу вбок, сделал кое-какие удивительные вещи суммирования - и, возможно, вполне мог передать результаты через гиперпространство - действительно произведение искусства. Я не мог даже представить себе что-то подобное и многому научился, просто научившись этому. Единственная проблема заключалась в том, что потребовалось 45 минут, чтобы запустить систему и поставить ее на колени. Мне понравился этот запрос ... но в конце концов ... я признаю это - я убил его. ((рыдает!)) Я расчленил его бензопилой, напевая «Шоссе в ад»! Я ... я написал небольшой процедурный код, чтобы скрыть мои следы, и ... никто не заметил. Я хотел бы сказать, что мне было жаль, но ... в конце концов работа заняла 30 секунд. О, конечно, достаточно легко сказать: «Но производительность имеет значение, понимаешь» ... но ... Мне понравился этот запрос ... ((фыркает ...)) Кто-нибудь видел мою бензопилу ...? >; ->

Смысл вышеизложенного: «Сделай все как можно проще, но не проще». Если вы обнаружите, что запрос содержит три страницы (я любил этот запрос, но ...), возможно, он пытается вам что-то сказать. Гораздо более простой запрос и некоторый процедурный код могут занимать примерно одинаковое пространство по страницам, но, возможно, их будет гораздо легче понять и поддерживать.

Делись и наслаждайся.

Answer 2

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

1. Приоритетность: вам следует попытаться договориться с «клиентом» и определить приоритеты функциональности.Скорее всего, не все одинаково полезно для них.

2. Управление ожиданиями: если у них нереальные ожидания, скажите им об этом приятным способом.

3. ИМХО SQL хорош во многих отношениях, но это не блестящий язык программирования.Поэтому я предпочел бы просто выполнять вычисления в приложении, а не в базе данных.

4. Я думаю, что я бы пошел на некоторую задержку в системе ... возможно, кэшируя вычисленные результаты для некоторыхминут до пересчета.Это с расчетом на производительность.

Answer 3

Короткий ответ: для анализа больших объемов данных база данных SQL, вероятно, является лучшим инструментом.

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

Answer 4

Люди обычно используют стороннюю систему написания отчетов вместо написания SQL.Как разработчик приложения, если вы тратите много времени на написание сложных отчетов, я бы серьезно усомнился в действиях вашего менеджера, не покупая готовое решение и позволяя менее опытным людям создавать свои собственные отчеты, используя некоторый графический интерфейс.1001 *

Answer 5

Для одноразового отчета я напишу код, который будет производить его так, как мне будет лучше.

Для отчета, который будет сгенерирован более одного раза, я проверю, кто будет его готовить в следующий раз. Я все равно напишу код в том виде, в котором у меня есть наилучшие доводы, но я мог бы добавить что-нибудь, чтобы сделать его более привлекательным для использования другим человеком.