Выбираем меньшее из зол в вопросе оптимизации



Автор - Евгения



В этой заметке я предлагаю поразмышлять над выбором решения, которое предотвратит звонок разъярённого админа с фразой «Какая … опять положила сервак?!».



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



Но давайте рассмотрим ситуацию, когда, казалось бы, без запроса в цикле не обойтись.



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



🔸1 – решение в лоб (и наиболее часто встречаемое) – запрос в цикле. Для каждой строки файла мы делаем запрос к базе, получаем данные из базы, формируем запись, пишем.



Особенности:



1. DDoS-атака на сервер. Если объём данных мал – ничего страшного. Если много – ждите звонка админа.



2. Долго..



Попробуем избежать исключения с экзамена.. И сделать так:



🔸2 – Считываем файл в таблицу значений, индексируем колонку артикул. Нужные данные из БД получаем запросом, с отбором по артикулу(массив, выгруженный из первой таблицы). Далее, используя метод найти, формируем запись, соединяя данные двух таблиц, пишем.



Особенности: Долго. Мы теряем время на создание индекса. Потом поиск. Потом запись. Кушаем оперативку. Но в целом вариант уже лучше, чем первый.



🔸3- Как и в варианте 2, считываем данные из файла в таблицу значений. Рисуем запрос к БД для получения дополнительной информации, используя первую таблицу как временную таблицу и уже к ней соединением крепим данные из БД. На выходе у нас выборка, по мере обхода которой, формируем запись и пишем.



Особенности метода: Кушаем оперативную память. Временная таблица не всегда является оптимальным решением. Сервер по собственному разумению может сбросить нашу временную таблицу на диск, и мы теряем скорость. Опасность неконтролируемого разрастания TempDB (это в целом про временные таблицы. Маловероятно, что конкретно наша задача будет виновником данной ситуации). Но в большинстве случаев вариант отработает быстрее чем вариант 2.



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



----------------------



Пост написан по программе "Напиши пост сам".



У Евгении есть свой канал по тематике ИТ и 1С: 1024B



Поддержите лайками и подпиской!