Я хотел бы задать ваше мнение по моему делу. У нас большой стол. И ежемесячно мы сообщаем об этом. То есть нам нужно загрузить до 20000 записей в формате PDF или Excel и распечатать их. Я планирую создавать отчеты в режиме реального времени. Нет заранее. Это хороший способ решить мою проблему? или если у вас есть идея лучше, я бы хотел ее услышать.Помогите принять решение об огромных отчетах
Благодаря
Это зависит от того, если вы собираетесь генерировать этот PDF-много. Если вы часто генерируете это, лучше всего кэшировать последний сгенерированный PDF-файл в течение 15-30 минут, чтобы избежать постоянной обработки этой «большой таблицы».
Потребуется некоторое время, чтобы получить все эти данные, но если вы не против задержки, это может быть хорошим решением не генерировать его заранее.
Если у вас есть много людей, обращающихся к PDF-файлу, и вы не хотите задержки, и данные не меняются очень быстро, вы, вероятно, должны их генерировать заранее. Интервал генерации должен соответствовать тому, насколько быстро ваши данные устаревают. Если данные изменяются, возможно, один раз в день, ежедневного обновления обычно достаточно. Если данные сильно изменяются, вы можете генерировать каждые 30 минут или около того.
Так что это зависит от того, кто будет получать доступ к PDF и как часто.
Я не совсем понимаю ваш вопрос; но когда мне нужно делать отчеты в реальном времени на действительно больших таблицах или на нескольких действительно больших таблицах, то я делаю предварительный расчет всех итогов, которые я хочу.
Таким образом, вместо запросов, как:
SELECT COUNT (*), сумма (товар) * цена, DateField, тип от Bigtable BT присоединиться reallybigtable RBT на bt.id = rbt.rbtid где DateField между «1 января 2009 года» и «31 января 2009 года» группа по типу, датафит
У нас будет хранимая процедура, рассчитанная ежедневно на каждую вторую таблицу, - тогда ее просто вопрос сложения 30 дневной стоимости предварительно рассчитанных итогов, а не для подсчета голосов и суммирования бай-иллионных записей.
Если вы создаете этот большой отчет, трудно представить, что пользователи ожидают частое обновление. В целом, я полагаю, что люди приносят очень большую ценность для того, чтобы ежедневно загружать последовательные повторяемые представления в лучшем случае. Фактически, эта согласованность/повторяемость обычно является хорошей причиной для обновления отчетов не чаще, чем ежедневно, а затем хранения результатов.
Если конкретный отчет вряд ли понадобится ежедневно или чаще, вы можете создать ленивое поколение отчетов, сохранить копию с первого раза, когда она создана в течение определенного дня, и, возможно, использовать схему имен файлов, например, RepABC_05032009.xls "в качестве маркера для отчета данного дня.
20000 записей действительно не так уж и много, поэтому генерация «на лету», безусловно, будет работать нормально (если запрос на получение этих записей не будет сложным/медленным).
Я рекомендую использовать Excel, потому что его намного проще реализовать. Просто выведите данные csv (у PHP есть готовые функции для этого) и отправьте соответствующий заголовок содержимого в ответ.
Еще одна причина для Excel вместо PDF заключается в том, что пользователи могут делать небольшие изменения и модификации перед печатью (изменение ориентации ландшафта/портрета, номеров строк, добавление пользовательской заметки и т. Д.).
Является ли это хорошим способом решения вашей проблемы? AFAICT, вы только указали свои требования (a) 20 000 записей; (b) PDF или Excel, один из которых напечатан (!); (c) генерировать в реальном времени – derobert
Вы забыли упомянуть, в чем проблема, с которой вы столкнулись. –
У меня есть идея, что этот пользователь просто ищет общий совет здесь. –