a_voronina_voroninYagrus2,


А вообще есть партиционирование

Пришла дикая мысль. А если сделать INSTEAD OF INSERT TRIGGER на вьюху. И в триггере кидать данные по таблицам. Кто-то делал такое? Насколько это адекватно по производительности?Эта мысль сразу в голову приходит, для описанной задачи. Как и распределённое представление.

Но производительность упадёт, ведь это будет уже не балк инсёрт, а куча инсёртов в кучу таблиц с фильтром по колонке, так сказать, "полю секционирования".

Вот для распределённого представления шанс есть. Наверное. Может, сиквел такой умный, и из одного потока сделает несколько балк-ов, ведь это именно "распределённое представление", а не абстрактный уод.

a_voroninКидать в разные таблицы по любому придется и фильтровать входной поток тоже. Вопрос насколько эффективно это в SSIS и насколько в триггере?

Откуда такое заявление про "обвалиться производительность"?Там же нельзя фимльтровать поток.
Там будет 20 (например, если 20 периодов) инсёртов с select из inserted с условием по полю, то есть 20 сканов этой псевдо-таблицы.

a_voroninЯ предполагаю, что скан Inserted является на два порядка более быстрой операцией, чем вставка в физическую таблицу. Тем более, что она скорее всего, храниться в некоей быстрой памяти или уже закеширована в память.Вставка в таблицу будет в любом случае.
А скан, конечно, быстрый, но если сканов много... Не говоря уже о том, что inserted может получиться такой, что памяти не хватит.

tunknownBOLBULK INSERT
[ database_name . [ schema_name ] . | schema_name . ] [ table_name | view_name ]
FROM 'data_file'
SSIS обязателен? Если источник подходящий, то BULK INSERT неплох.Так вопрос в том, будет ли работать BULK INSERT при вставке из триггера, или вставке во VIEW.

Вот из SSIS с Conditional Split точно будет максимально быстро, а остальные варианты нужно проверять.