Помогите принять решение по огромной отчетности

Question

Я хотел бы спросить ваше мнение по моему делу. У нас большой стол. И ежемесячно мы делаем отчеты по этой таблице. То есть нам нужно загрузить до 20000 записей в формате PDF или Excel и распечатать их. Я планирую создавать отчеты в режиме реального времени. Нет заранее поколения. Это хороший способ решить мою проблему? или если у вас есть идея получше, я бы хотел ее услышать.

Спасибо

Answer 1

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

Так что вместо запросов вроде:

выберите количество (*), сумму (элементы) * цена, поле даты, тип от большой таблицы BT присоединиться к действительно большому rbt на bt.id = rbt.rbtid где поле даты между «1 января 2009 года» и «31 января 2009 года» сгруппировать по типу, поле даты

У нас будет хранимая процедура, которая подсчитывает ежедневные итоговые значения каждую ночь для второй таблицы - тогда достаточно просто сложить предварительно рассчитанные итоги за 30 дней, а не подсчитать объединение и суммирование ба-зиллионов записи.

Answer 2

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

Если данный отчет вряд ли понадобится ежедневно или чаще, вы можете создать отложенный отчет, сохранив копию с первого раза, когда он был создан для данного дня, и, возможно, использовать схему именования файлов, например, "RepABC_05032009 .xls "как маркер для отчета за день.

Answer 3

Это зависит от того, будете ли вы много создавать этот PDF. Если вы генерируете это часто, то, вероятно, будет лучше кэшировать последний сгенерированный PDF на 15–30 минут, чтобы избежать постоянной обработки этой «большой таблицы».

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

Если у вас есть много людей, которые обращаются к PDF и не хотят задержек, и данные не меняются очень быстро, вам, вероятно, следует сгенерировать их заранее. Интервал генерации должен соответствовать скорости устаревания ваших данных. Если данные меняются один раз в день, обычно достаточно ежедневного обновления. Если данные сильно меняются, вы можете генерировать каждые 30 минут или около того.

Так что это зависит от того, кто будет обращаться к PDF и как часто.

Answer 4

20000 записей на самом деле не так уж велики, поэтому генерация «на лету», безусловно, будет работать нормально (если запрос для получения этих записей не сложный / медленный).

Я рекомендую использовать Excel, потому что его гораздо проще реализовать. Просто выведите данные csv (для этого в PHP есть готовые функции) и отправьте соответствующий заголовок содержимого в ответ.

Другая причина использования Excel вместо PDF заключается в том, что пользователи могут вносить незначительные изменения и модификации перед печатью (изменение макета ландшафта / портрета, номеров строк, добавление пользовательских заметок и т.