Yagrus2Hello world!
Стоит задача разбивать данные таблицы-источника по годам и класть их в соответствующие таблицы-назначения. Например, за 2018 год данные должны попасть в T_2018, а за 2017 в T_2017.
Подскажите, возможно ли это сделать используя data flow task и его expressions?Испоьзуйте внутри таска Conditional Split

FerdipuxmsLexАвтору destination менять нужно, а не source.

Yagrus2,
Если список получателей динамический, используйте Script Component в качестве destination.


Если таблицы имеют одинаковый набор колонок, их названия и тип - то вполне работает метод с именем таблицы из переменной в OLE DB Destination. Попроще будет чем программировать Script Destination, динамику тоже поддерживает.Не пойму, для каждой строки из исходной таблицы нужно будет менять OLE DB Destination?
По моему, вы не понимаете, в чём задача :-)

Таким способом можно перебрать OLE DB Destination в цикле, но тогда придётся делать исходную выборрку столько раз, сколько будет разных OLE DB Destination, что неэффективно

Так зачем замедлять, если есть специально предназначенный для разделения потока данных Conditional Split?

GlebanskiА почему никто не предлагает сделать partitioned view, под ним таблицы с Constraints на даты? Тогда destination вообще один будет, а все записи поза вас сервер по таблицам раскидает.Мда, что то в голову не пришло, обычно в таких случаех это и советовали...
Единственно, балк инсёрт при этом невозможен, производительность Data Flow task резко упадёт, и, соответственно, применимость такого решения зависит от объёмов данных.

Yagrus2Но не вышло, получил ошибку:
[Execute SQL Task] Error: There is an invalid number of result bindings returned for the ResultSetType: "ResultSetType_Rowset".
Всегда должна быть одна переменная?В смысле, вы хотите положить одно значение в 2 переменных?
Так нельзя, да, всегда должна быть только одна переменная.

Yagrus2alexeyvg,
Нет.
Запрос возвращает два столбца. Каждый столбец хотел бы положить в свою переменную типа ObjectНу, для типа ResultSetType_Rowset весь рекордсет возвращается как одно значение.
Да и зачем это нужно, ну, будет 2 коллекции с записями, вместо одной, это же неудобно, как сопроставлять записи?

Yagrus2alexeyvgНу, для типа ResultSetType_Rowset весь рекордсет возвращается как одно значение.
Да и зачем это нужно, ну, будет 2 коллекции с записями, вместо одной, это же неудобно, как сопроставлять записи?
А для чего тогда есть возможность создавать несколько отношений между Rowset - ом и переменными?

Вообще справа внизу окошка есть кропка с надписью Help, при нажатии которой вам будет показано нечто интересное :-)
В частности:
"If the result set type is Full result set or XML, you must use 0 as the result set name."

А возможность создавать несколько отношений между Rowset - ом и переменными предназначена для другого типа возврата - Single row
В этом случае в каждую переменную записывается значение из первой строки рекордсета, из колонки, имя которой указано в Relult Name
Это всё тоже описано в том же хелпе, с примерами, как потом использовать результаты.

Владислав КолосовSQL выражение может вернуть несколько наборов данных. При этом для каждого можно определить свою переменную-объект.Разве? Я думал, что остальные рекордметы (и соответстенно маппинг) игнорируются. По крайней мере так описано в хелпе; впрочем, работать может и не совсем так, как описано :-)
"If the Execute SQL task uses the Full result set result set and the query returns multiple rowsets, the task returns only the first rowset . If this rowset generates an error, the task reports the error. If other rowsets generate errors, the task does not report them."

FerdipuxВладислав Колосовдавно не брал в руки шашки, но, насколько я помню, для разных драйверов по-разному. Для OLE DB они нумеруются с нуля и дальше. Рекордсет номер 2 будет иметь номер 1 и так далее.
Это вы путаете колонки и рекордсеты. Для OLEDB - колонки имеют номера, начиная с 0, для ADO.NET - можно использовать имена.Да, тоже припоминаю, что в одном случае колонки по номерам, а в другом по именам.

Значит, всё таки несколько рекордсетов использовать нельзя :-(

Жаль, всё таки принцип наличия нескольких рекордсетов - фишка, выгодно выделявшая сиквел, но почему то нельзя это использовапть как внутри сиквела, так и в миерософтовких клиентах, типа SSIS или SSRS.

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 точно будет максимально быстро, а остальные варианты нужно проверять.