У нас була подібна проблема зі звітами BIRT, оскільки ми хотіли звітувати про ті дні, що не мали даних. Оскільки записів для цих дат не було, найпростішим рішенням для нас було створити просту таблицю, яка зберігала б усі дати, і використовувати її для отримання діапазонів або об’єднання для отримання нульових значень для цієї дати.
У нас є робота, яка працює щомісяця, щоб забезпечити заповнення таблиці через 5 років у майбутньому. Таблиця створюється таким чином:
create table all_dates (
dt date primary key
);
Без сумніву, є магічні хитрі способи зробити це за допомогою різних СУБД, але ми завжди обираємо найпростіші рішення. Вимоги до зберігання таблиці мінімальні, і це робить запити набагато простішими та портативнішими. Таке рішення майже завжди є кращим з точки зору продуктивності, оскільки воно не вимагає обчислень даних у рядках.
Інший варіант (і ми вже використовували це раніше) полягає в тому, щоб переконатися, що в таблиці є запис для кожної дати. Ми періодично підбирали таблицю і додавали нульові записи для дат та / або часу, яких не було. У вашому випадку це може не бути опцією, це залежить від збережених даних.
Якщо ви дійсно вважаєте клопотом збереження all_dates
таблиці заповненою, збережена процедура - це шлях, який поверне набір даних, що містить ці дати. Це майже напевно буде повільнішим, оскільки вам доведеться обчислювати діапазон кожного разу, коли він викликається, а не просто витягувати заздалегідь обчислені дані з таблиці.
Але, чесно кажучи, ви могли б заповнити таблицю на 1000 років без будь-яких серйозних проблем із зберіганням даних - 365 000 16-байтових (наприклад) дат плюс індекс, що дублює дату плюс 20% накладних витрат на безпеку, я б приблизно оцінив на близько 14 млн. [365 000 * 16 * 2 * 1,2 = 14 016 000 байт]), мінімальна таблиця на схемі речей.