У нас была аналогичная проблема с отчетами 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 байт]), крохотная таблица в схеме вещей.
04.02.2009