Итак, я сохранил процедуру, которая будет использоваться для извлечения данных, которые будут импортированы в другую таблицу в течение длительного периода времени. '2020-01-01' по '2022-02-28' Я хочу делать это партиями по 7 дней. Я не хочу вручную запускать PROC и проходить 7-дневный диапазон в течение 2 лет.
Псевдопример:
INSERT INTO dbo.MyImportedData
INSERT INTO dbo.MyImportedData
EXEC [dbo].[MyLongRangeData]
@StartDate = @StartDate,
@EndDate = @EndDate -- First 7 Day Period (2020-01-01 to 2020-01-07)
INSERT INTO dbo.MyImportedData
EXEC [dbo].[MyLongRangeData]
@StartDate = @StartDate,
@EndDate = @EndDate -- second 7 Day Period (2020-01-08 to 2020-01-14) --Doing this until 2022-02-28.
Заранее спасибо за помощь.
Могу я спросить, почему вы не пытаетесь добиться этого с помощью SSIS? Это позволит вам определить размер партии в строках, а не в датах, что намного лучше.
@Philippe Ну, нет, если отчет представляет собой еженедельные продажи или что-то в этом роде, где количество строк на самом деле является частью того, что вы хотите выделить, а не стабилизировать / сгладить.
@Aaron: Может быть, я неправильно понял проблему, но, как я вижу, задача состоит в том, чтобы скопировать много данных из одной таблицы в другую и разделить рабочую нагрузку на пакеты, ОП хочет копировать только 7 дней одновременно. Насколько я понял, к подсветке это отношения не имеет. Кроме того: в зависимости от содержимого и индексации может быть проще просто использовать столбец идентификатора для выбора. Если почти все идентификаторы отсутствуют, то выбор ПК может значительно повысить производительность.
@Philippe Мы просто не знаем, мы понятия не имеем, что делает процедура (может быть, она агрегирует?) Или почему в настоящее время она вообще принимает диапазон дат. Мы уверены, что это просто обработка меньшего количества строк за раз? Может быть? Может быть нет? Может быть, исходные данные суммированы или периодически повторяются и уже содержат постоянное количество строк за <любой период времени>? Может быть? Может быть нет?
Хорошо, поэтому PROC используется другими программами, которые обычно работают в течение короткого периода времени и имеют некоторую агрегацию, которую он делает. Теперь для этой цели это будет одноразовая вещь. Причина для 7-дневного диапазона - из соображений производительности. Если вы выходите за пределы 7, 10 дней, это вызывает недоумение у некоторых людей. @AaronBertrand, да, это больше похоже на то, что нужно сделать, и спасибо, что ваше решение сработало.
Предполагая, что вам просто нужны простые 7-дневные блоки и вам не нужно выравнивать их по первому дню года или финансовым периодам, вы можете сделать простой цикл, что-то вроде этого:
DECLARE @d date = '20200101', @e date;
WHILE @d <= '20220228'
BEGIN
SET @e = DATEADD(DAY, 6, @d);
INSERT dbo.MyImportedData(<always list columns here!>)
EXEC [dbo].[MyLongRangeData] @StartDate = @d, @EndDate = @e;
SET @d = DATEADD(DAY, 7, @d);
END
Но лучше было бы переписать процедуру (или создать новую) для обработки 7-дневных фрагментов для вас в любом диапазоне дат, чтобы вам не приходилось вызывать ее 100 раз.
Почему бы вам не переписать хранимую процедуру (или не создать копию), чтобы она выполняла цикл за вас, чтобы вам не приходилось вызывать ее более 100 раз? И как именно вы определяете «7-дневный период»? 1 января -> 7 января 2020 г., 8 января -> 14 января 2020 г., ... пока все ясно. Но что произойдет, когда вы достигнете 1 января 2021 года?