У нас была похожая проблема с отчетами BIRT в том, что мы хотели сообщать в те дни, когда данных не было. Поскольку для этих дат не было записей, самым простым решением для нас было создать простую таблицу, в которой хранятся все даты, и использовать ее для получения диапазонов или объединить, чтобы получить нулевые значения для этой даты.
У нас есть работа, которая выполняется каждый месяц, чтобы обеспечить заполнение таблицы на 5 лет в будущем. Таблица создана таким образом:
create table all_dates (
dt date primary key
);
Без сомнения, существуют магические хитрые способы сделать это с разными СУБД, но мы всегда выбираем самое простое решение. Требования к хранилищу для таблицы минимальны, и это делает запросы намного проще и портативнее. Такое решение почти всегда лучше с точки зрения производительности, поскольку не требует вычислений для каждой строки данных.
Другой вариант (и мы использовали это раньше) - обеспечить запись в таблице для каждой даты. Мы периодически просматривали таблицу и добавляли ноль записей для дат и / или времени, которых не было. Это может быть не вариант в вашем случае, это зависит от хранимых данных.
Если вы действительно думаете, что заполнение таблицы all_dates
затруднительно, то есть хранимая процедура, которая вернет набор данных, содержащий эти даты. Это почти наверняка будет медленнее, поскольку вы должны вычислять диапазон каждый раз, когда он вызывается, а не просто извлекать предварительно рассчитанные данные из таблицы.
Но, если честно, вы можете заполнить таблицу на 1000 лет без каких-либо серьезных проблем с хранением данных - 365 000 16-байтовых (например) дат плюс индекс, дублирующий дату плюс 20% накладных расходов на безопасность, я бы сказал, грубо говоря, около 14M [365 000 * 16 * 2 * 1,2 = 14 016 000 байт]), крошечная таблица в схеме вещей.