У меня есть некоторый SQL, который выполняет сложную логику для комбинаций номеров счетов GL и центров затрат, как это:
WHEN (@IntGLAcct In (
882001, 882025, 83000154, 83000155, 83000120, 83000130,
83000140, 83000157, 83000010, 83000159, 83000160, 83000161,
83000162, 83000011, 83000166, 83000168, 83000169, 82504000,
82504003, 82504005, 82504008, 82504029, 82530003, 82530004,
83000000, 83000100, 83000101, 83000102, 83000103, 83000104,
83000105, 83000106, 83000107, 83000108, 83000109, 83000110,
83000111, 83000112, 83000113, 83100005, 83100010, 83100015,
82518001, 82552004, 884424, 82550072, 82552000, 82552001,
82552002, 82552003, 82552005, 82552012, 82552015, 884433,
884450, 884501, 82504025, 82508010, 82508011, 82508012,
83016003, 82552014, 81000021, 80002222, 82506001, 82506005,
82532001, 82550000, 82500009, 82532000))
В целом, все это плохо работает в UDF, особенно когда оно все вложено, и порядок шагов важен и т. Д. Я пока не могу сделать это управляемым таблицей, потому что бизнес-логика так ужасно запутана .
Итак, я делаю небольшую исследовательскую работу по переносу его в SSIS, чтобы увидеть, как это сделать немного по-другому. Однако внутри моей задачи сценария я должен использовать VB.NET, поэтому я ищу альтернативу этому:
Select Case IntGLAcct = 882001 OR IntGLAcct = 882025 OR ...
Что, очевидно, намного более многословно и очень затруднит перенос процесса.
Даже что-то вроде ({90605, 90607, 90610} AS List(Of Integer)).Contains(IntGLAcct) было бы проще перенести, но я не могу заставить инициализатор выдать мне анонимный массив, подобный этому. И таких маленьких коллекций так много, что я не уверен, что смогу создать их заранее.
Это действительно все нужно быть в одном месте. Бизнес регулярно меняет эту логику. Моя стратегия заключалась в том, чтобы использовать udf для отражения их старого файла «include», но производительность была низкой. Теперь каждая из функций принимает всего 2 или три параметра. Оказывается, что в темном углу существующей системы они на самом деле строят многомиллионную таблицу строк со всеми этими результатами - даже несмотря на то, что предварительно вычисленная таблица используется редко.
Таким образом, мой новый эксперимент состоит в том, чтобы (поскольку я все еще строю массивную таблицу перекрестных соединений для согласования этой части процесса) идти дальше и использовать таблицу вместо кода, но продолжить и заполнять эту таблицу во время SSIS этап вместо того, чтобы вызывать udf 12 миллионов раз - потому что моя версия udf просто перестала работать в течение разумного периода времени, и администраторы баз данных сейчас не сильно помогают. Тем не менее, я знаю, что SSIS может обрабатывать эти строки довольно эффективно - потому что каждый месяц я привожу за несколько десятков миллионов таблиц строк из прежней системы за несколько хороших результатов и запускаю запросы, чтобы согласовать отсутствие различий с новыми версиями .
Код служб SSIS теоретически станет хранителем бизнес-логики, и из этого будет построена эффективная таблица (на основе всех известных комбинаций параметров). Конечно, если я смогу упростить логику до реальной логической таблицы, это было бы идеальным решением, но на данный момент это не совсем предсказуемо.