🙏😊 это хорошо, это похвально 👍

Спасибо, попробую так. Не помню, может и делал раньше, но при последних восстановлениях журнала не указывал move

#работа #москва #fulltime

Зарплатная вилка: от 180 до 300К рублей gross (по итогам собеседования)
Формат: офис\удаленка

В связи с открытием новых проектов Инвестиционная компания  «Ай Ти Инвест» ищет разработчика баз данных (MS SQL Server). Мы работаем больше 20 лет и являемся надежной, технологичной и стабильной компанией.

Ключевые задачи:
-Разработка и поддержка интеграционных решений для системы backQORT;
-Разработка отчетов из базы данных системы backQORT;
-Участие в иных интеграционных проектах ИТ департамента с использованием баз данных.

Для нас важно:
-Хорошее знание SQL,T-SQL;
-Опыт оптимизации запросов;
-Навыки администрирования MS SQL Server;
-Знание английского языка на уровне intermediate;

Будет преимуществом:
-Опыт интеграции с системой backQORT;
-Опыт использования MS SQL Server Integration Services, MS SQL Server Reporting Services и MS Analysis Services.

Мы предлагаем:

-Работу в инвестиционной компании с 20-летним опытом работы на рынке.
-Оформление по ТК РФ, белая заработная плата (оплачиваемые переработки, премии, бонусы);
-График работы: с 10-00 до 19-00.
-Удобный формат работы: удаленка/офис
.
Чтобы узнать больше о компании и вакансии, напишите мне в telegram.

просьба поддержать звездами задумку Joe Obbish https://github.com/jobbish-sql/SQL-Server-Multi-Thread
уже сейчас работает довольно стабильно

Подскажите, знатоки запросов)

Есть таблица. В ней поле с типом XML, примерно следующего
содержания

<Extension>
 <Item Key="CardAcceptorIDCode" Value="407570" />
 <Item Key="AcquiringInstitutionIDCode" Value="5050" />
 <Item Key="MerchantCategoryCode" Value="6012" />
 <Item Key="ProcessingCode" Value="CashAdvance" />
 <Item Key="ApprovalCode" Value="407681" />
 <Item Key="ResponseCode" Value="Approved" />
 <Item Key="AvailableBalanceCurrency" Value="643" />
 <Item Key="RRN" Value="925202003222" />
 <Item Key="Utrnno" Value="11121212312" />
</Extension>

Пытаюсь отфильтровать те записи, где в XML по ключу /Extension/Item
Key = "Utrnno"

План в итоге не очень. Стоимость запроса какая-то космическая.

Выполняется 2 мин 42 сек. Возвращается - 600 000 записей

Сам запрос:

;with cardoperation as
(
select * from DB.dbo.card_operations with (nolock)
)
SELECT x.m.value('@Value[1]', 'nvarchar(MAX)') AS value
FROM cardoperation
OUTER APPLY attributes.nodes('/Extension/Item') x(m)
WHERE x.m.value('@Key[1]', 'nvarchar(MAX)')='Utrnno'

Как оптимизировать данный запрос?

OUTER APPLY attributes.nodes('/Extension/Item[@Key="Utrnno"]') x(m) для начала

Изменил. Быстрее стало, но в результирующей колонке сплошняком NULL(

Это атрибут, да.  OUTER APPLY attributes.nodes('/Extension/Item[@Key="Utrnno"]') x(m)

Да

Добавил @.

Добавил. Спасибо. Запрос в 2 раза быстрее выполняется. Но в плане стоимость мало изменилась

И еще предупреждение:

Это никак не улучшить?

можно убрать OUTER APPLY attributes.nodes если точно известно, что этот узел в xml ровно один - положить весь путь в value примерно так  

select *, co.attributes.value('(/Extension/Item[@Key="Utrnno"]/@Value)[1]', 'nvarchar(MAX)') AS value
from DB.dbo.card_operations co with (nolock)

но если в большинстве строк xml есть и в нем есть этот узел - при отсутствии индекса по этому пути с парсингом мало что можно сделать, разве что поработать с ним как со строкой.

Узел вроде бы один.
Ок, сейчас попробую

Я б минус поставил, если можно

Я боюсь, что никак...

“Я б” - вся сущность ответа. Думаю здесь мало кому интересна дискуссия о подходе параллельного выполнения TSQL кода данного фреймворка, поэтому если есть развернутый ответ с критикой, то лучше сразу его оформить в виде issue на github к данному репо, но прежде чем это делать все таки надо потратить минут 30 хотя бы на демо примеры, чтобы критика была конструктивной - с предложением альтернатив и желательно с тестированием их сравнительной производительности.
Я не тролю, просто устал читать ответы в чате в 3 слова без объяснения мнения и пруфов тестирования.

Мне не нравится подход, использующий джобы, как таковой, потому что это приводит к тому, что в агенте начинается хаос и простого интерфейса для понимания того, что, вообще, сейчас работает, нет, а встроенным пользоваться уже не получается нормально.
Я за то, чтоб юзать ssis с параметрами, в 100 раз прозрачнее получается.

ключевое слово здесь SSIS - можно заменить любым другим ETL инструментом, ничего не поменяется. не всегда это можно сделать, а поддерживать SSIS (или любую другую ETL/ELT приблуду) еще то интересное занятие. здесь бы логичнее было Service Broker вспомнить, но с ним тоже надо уметь работать (и это еще мягко сказано), а вот данный фреймворк предлагает большой функционал из коробки - единственное требование работающий агент. Я не говорю что это идеальный инструмент и его надо начать всем использовать, но внимание он точно заслуживает (некоторые паттерны я уже запланировал добавить в тестовую реализацию).
Просто получается по классике - “не читал, но осуждаю”