Условное разделение служб SSIS - несколько условий - PullRequest
Новая
       47

Условное разделение служб SSIS - несколько условий

1 голос
/ 29 декабря 2011

Я пытаюсь проверить, изменился ли какой-либо из столбцов. Я попытался поставить все в условии: 

Taxes != (ISNULL(LookupTaxes) ? 0 : LookupTaxes) || Checksum != (ISNULL(LookupChecksum) ? 0 : LookupChecksum) || FeeIncome != (ISNULL(LookupFeeIncome) ? 0 : LookupFeeIncome) || CommissionReceived != (ISNULL(LookupCommissionReceived) ? 0 : LookupCommissionReceived) || CommissionPaid != (ISNULL(LookupCommissionPaid) ? 0 : LookupCommissionPaid) || Premium != (ISNULL(LookupPremium) ? 0 : LookupPremium)

но это всегда возвращает FALSE, хотя я вручную изменил налоги. Если я ставлю каждое условие отдельно, чем оно работает, например: 

Taxes != (ISNULL(LookupTaxes) ? 0 : LookupTaxes)

возвращает TRUE. Если я использую 6 условий (вместо 1) для каждого столбца и выводю результаты в Union All, дает ли мне этот метод то, что мне нужно? Больше всего меня беспокоит, будут ли строки дублированы. Я проверил и похоже, что это не так, но мне интересно, почему некоторые условия выбирают X записей, а другие Y, когда я изменил оба столбца (связанные с этими двумя условиями). Например, все столбцы «Налоги» и «Премиум» изменены. В выводе «Условное разбиение» условие «Налоги изменились» выбирает 1000000 строк, а «Премиум изменилось» - 100 строк. Я знаю, что это не имеет никакого значения в моем случае, потому что для меня важно, чтобы эти строки были выбраны для обновления, но я просто не понимаю, как это работает.

Ответы [ 3 ]

2 голосов
/ 31 декабря 2011

Я считаю, что ваша логика правильна, но я бы посоветовал вам разбить все эти цепочечные условия на отдельные производные столбцы, особенно если через него будет проходить 1 млн строк.

Первая причина - производительность. Разбивая операции на более мелкие части, механизм потока данных может лучше использовать преимущества параллелизма. Исследование. Могут ли разные комбинации компонентов влиять на производительность потока данных? . Цитата денег от SQL CAT по теме

Наше тестирование показало, что если вы хотите изменить более одного столбца в потоке данных с помощью задачи «Производный столбец» существует производительность Преимущество разделения этого преобразования на несколько производных столбцов задачи. В этой заметке мы покажем, что делать много мелких кусочков работа в нескольких задачах производного столбца значительно быстрее, чем делать всю работу в более сложной работе в одной производной колонке задача.

Вторая причина - ремонтопригодность. Редактор выражений не только недружелюбен и не прощает, но и делает проверку промежуточных значений невероятно сложной.

Демо

Я собрал пакет воспроизведения, который использует задачу сценария для отправки N строк вниз по потоку данных с тем же значением во всех столбцах, что и номер строки. В первом потоке данных я изменяю значения Checksum и Premium при загрузке в диспетчер соединений кеша (для имитации различий в значениях поиска). Четные строки должны иметь нулевую контрольную сумму, а каждый третий ряд должен иметь нулевой премиум. ​​

cache connection manager load

В этом потоке данных я использовал как исходное выражение (все в одной проверке), так и разбил его на проверку по условию.

data flow

Как вы можете , может быть увидеть в просмотрщике данных, прикрепленном к задаче «битовая корзина», измененные столбцы с именами после исправления имеют значение True только тогда, когда есть разница между исходным значением и значением поиска. (Строка, соответствующая 0 , является точной, поскольку (ISNULL(LookupTaxes) ? 0 : LookupTaxes) приводит к тому, что нулевые значения равны нулю.

data viewer

Если бы вы были на этом этапе, я бы заменил преобразование "битовая корзина" условным разбиением

  • Имя выхода = UpdateRequired
  • Состояние = [TaxesChanged] || [ChecksumChanged] || [FeeIncomeChanged]|| [CommissionReceivedChanged] || [CommissionPaidChanged] || [PremiumChanged]

Если у вас по-прежнему возникают проблемы, вы можете включить средство просмотра данных в конвейер, чтобы найти условия, которые не оцениваются должным образом.

1 голос
/ 23 февраля 2012

Альтернативой является использование преобразований потока данных (DFT) с двумя производными столбцами до условного разделения DFT.

Производный столбец DFT 1: Проверьте для каждого атрибута значение 1, если в данных есть изменения, и 0, если изменений нет.Например, проверьте значение входящего столбца «Данные о рождении» в столбце «Дата рождения» в базе данных. 

   DerivedColumn1 =  ((!ISNULL(InDOB) && !ISNULL(DbDOB) && InDOB != DbDOB) || (ISNULL(DbDOB) && !ISNULL(InDOB))) ? 1 : 0

Результатом DerivedColumn1 является целочисленное значение со знаком = 1 или 0.

DerivedColumn2:Суммируйте значения производного столбца из DFT1.

   IdentifiedChange = DerivedColumn1 + DerivedColumn2 + ....

Условное разделение DFT: указывает, есть ли изменение в данных, как определено результатом DFT2.

   YesChange   IdentifiedChange > 0

Надеюсь, это поможет.

0 голосов
/ 30 мая 2014

На самом деле ответ будет следующим: 

(Taxes != (ISNULL(LookupTaxes) ? 0 : LookupTaxes)) ||
(Checksum != (ISNULL(LookupChecksum) ? 0 : LookupChecksum)) ||
(FeeIncome != (ISNULL(LookupFeeIncome) ? 0 : LookupFeeIncome)) ||
(CommissionReceived != (ISNULL(LookupCommissionReceived) ? 0 : LookupCommissionReceived)) ||
(CommissionPaid != (ISNULL(LookupCommissionPaid) ? 0 : LookupCommissionPaid)) ||
(Premium != (ISNULL(LookupPremium) ? 0 : LookupPremium))

Требуются дополнительные "(" и ")" в начале и в конце каждой переменной проверки.||(ИЛИ) условие будет думать, что налоги! = ИЛИ условие, как в первой части вашего условия.

Это будет работать.

...