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