Транспонирование периодов с "порциями" - неизвестное максимальное количество строк
Привет всем!
Ситуация. Есть отчет по платежам клиента. Максимально возможное количество платежей неизвестно. Заказчик хочет видеть в отчете периоды в столбцах, а не построчно (как хранятся данные в таблице). Соответственно написана табличная функция со "скроллингом", которая возвращает результат по одной "порции"-строке (по шесть столбцов в каждой - столько влезает на страницу) в зависимости от входящих параметров "rowbegin", "rowend".
select * from quest.dbo.fn_transpose(@clientid, rowbegin, rowend) t
Для каждой такой "порции" заведен свой датасорс, соответственно свой датабэнд.
Все работает, заказчик доволен. Только на тестовых данных максимальное количество периодов 14, а на бОльшем массиве протестировать нет возможности. Сейчас заведено датасорсов и датабэндов 10 штук "впрок" (сейчас хватает и трех), а сколько может быть максимум - неизвестно. Может попастся клиент с историей 20 лет, соответственно периодов будет 240, а датасорсов и датабэндов в таком случае при данном алгоритме: 240 / 6 = 40.
Такое количество заводить не хотелось бы, хотя это в принципе возможно. Да и скорость формирования отчета какая будет с таким количеством обращений к базе...
Подскажите более "изящное" решение вопроса плз.
Ситуация. Есть отчет по платежам клиента. Максимально возможное количество платежей неизвестно. Заказчик хочет видеть в отчете периоды в столбцах, а не построчно (как хранятся данные в таблице). Соответственно написана табличная функция со "скроллингом", которая возвращает результат по одной "порции"-строке (по шесть столбцов в каждой - столько влезает на страницу) в зависимости от входящих параметров "rowbegin", "rowend".
select * from quest.dbo.fn_transpose(@clientid, rowbegin, rowend) t
Для каждой такой "порции" заведен свой датасорс, соответственно свой датабэнд.
Все работает, заказчик доволен. Только на тестовых данных максимальное количество периодов 14, а на бОльшем массиве протестировать нет возможности. Сейчас заведено датасорсов и датабэндов 10 штук "впрок" (сейчас хватает и трех), а сколько может быть максимум - неизвестно. Может попастся клиент с историей 20 лет, соответственно периодов будет 240, а датасорсов и датабэндов в таком случае при данном алгоритме: 240 / 6 = 40.
Такое количество заводить не хотелось бы, хотя это в принципе возможно. Да и скорость формирования отчета какая будет с таким количеством обращений к базе...
Подскажите более "изящное" решение вопроса плз.
Комментарии
Кроме, конечно же, такого нюанса:
Если база разрастется настолько, что отчет не будет формироваться из-за длительной обработки данных, то нужно будет оптимизировать запросы, применять индексы и т.д. Конечно же, хотелось бы уже сейчас избежать большого количества обращений к базе в одном отчете.
А пока что придумал способ обращаться к промежуточному датасорсу, в котором "зашиты" значения datbeg и datend:
А уже от этого бэнда идет дочерний бэнд, в котором привязанный датасорс обращается к родительскому для получения значений rowbeg, rowend.
Работает.