Недавно я консультировал по поводу рефакторинга некоторого кода обработки данных, и одна часть системы собирает некоторые промежуточные наборы данных в таблицах, а затем вставляет некоторые сводные / сводные записи в пару отдельных таблиц. Поскольку промежуточные данные фактически не используются, кажется, что это пустая трата ресурсов для их материализации на диске только для того, чтобы использовать их для некоторой «последующей» обработки. Например, создается таблица A, и затем появляются операторы INSERT-SELECT (все с таблицей A в их предложениях FROM), добавляющие записи в таблицы B, C и D. Таблица A усекается после вставки в нее B, C и D.
Если бы была одна таблица выходных данных, у меня не возникало бы никаких вопросов - просто включите оператор SELECT для промежуточных данных в заключительный оператор INSERT-SELECT. Но так как есть три выхода, я не знаю, как написать один запрос, который выполняет это. Самое близкое, что я могу придумать, - это включить общую логику в каждый INSERT-SELECT, что вместо этого приведет к избыточной обработке, что является еще одной формой потерь.
Можно ли вставить несколько таблиц в одном SQLоператор?
Примечания:
- Я мог бы использовать временную таблицу или табличную переменную для хранения промежуточных данных, но это по-прежнему предполагает сохранение промежуточных данных программистом. Отчасти мой вопрос заключается в том, что если бы возможна такая многопластовая вставка, то Query Optimizer / DB Engine будет обрабатывать это промежуточное хранилище данных вместо программиста, вероятно, справляясь с этой задачей лучше.
- Я знаю, чтоЯ должен выбрать альтернативу, основанную на тестировании производительности, а не рассуждать о том, что может быть быстрее или медленнее, но этот вопрос не о выборе альтернативы. Спрашивается, существует ли конкретная альтернатива или нет.