Интервалы между датами для простого хранилища данных в PHP

Question

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

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

Например, между «2009-06-29» и «2011-06-29» прошло 2 года, однако мы должны знать, что этот диапазон состоит из одного полного года (2010), одиннадцати месяцев (Январь-май / 10 и июль-декабрь / 09) и 58 дней (июнь 1-29/09 и июнь 1-29/11).

Из этого результата мы можем извлечь уже обобщенные записи из 70 гранулярных периодов, объединить и представить итоги.

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

1. Заполните массив «dateToParse» начальным диапазоном дат.
2. Определите, существует ли один или несколько полных лет между датами.
   • Для каждого года между датами удалите этот период из диапазона дат и разделите «период до» и «период после» года на два новых диапазона дат.
   • Вставьте два новых диапазона дат в стек «dateToParse».
   • Повтор
3. Когда все возможные годы были удалены из «dateToParse»массив, повторите процесс в течение нескольких месяцев, недель и дней.

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

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

Answer 1

Я не понимаю, почему вы хотите реализовать такое сложное решение, обычная реализация состоит в том, чтобы иметь только одну таблицу фактов с данными на самом низком уровне детализации (в вашем случае ежедневно) и просто SUM () вверх меры в ваших запросах по мере необходимости.

Это очень просто реализовать и поддерживать, а запросы очень легко писать (или генерировать из вашего инструмента отчетности). Это не работает для вас? Какой объем данных у вас есть? Вы реализовали дату как измерение (надеюсь, да) или как значение в таблице фактов? Используете ли вы инструмент отчетности (SSRS, Cognos, Business Objects) или выполняете собственные запросы?

Если вы думаете о проблемах с производительностью, вполне вероятно, что DWH будет развиваться следующим образом:

1. Реализация единой таблицы фактов (как описано выше)
2. Добавить много данных
3. Обнаружение проблем с производительностью при увеличении объема данных
4. Улучшение индексации
5. Реализация разбиения таблиц
6. Реализация OLAP

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