Как минимум мне нужно:
Встроить в нетленку - автоматическу выгрузку изменившихся данных за указанный период. И обсеспечить их загрузку в бухию. С последующим контролем корректности загруженных данных с возвратом результата контроля в нетленку.
КД2 в этом всем только поможет мне облегчить процедуру сопоставления полей у выгружаемых объектов. А как только в КД2 я полезу в закладку Алгоритмы - начнутся сложности.... и я буду вынужден ради использования комбайна их терпеть.

Я вот посматриваю иногда в модули БСП. И волосы на затылке приподымаются от понимания сколько там "обвязок" которые мне в моей нетленке вообще не нужны. Поэтому беру оттуда "суть" и повторяю у себя.
Да, если бы я сразу всю БСП внедрил - приобрел бы профит в виде знания БСП, как доп.скил. Но ... как-то не сложилось.. чего уж теперь.

Всем привет, есть вопрос знатокам, чем плохо такое использование оператора подобно, кроме индексов?

В данном случае подобно  (шаблон%) отработает неплохо.
Но там соединение и скорее всего оптимизатор промахнется/
UPD возможно и не соединение, а данные ВТ, но все равно не литерал - оптимизатору будет тяжко

т.е проблемы исключительно в индексе?
если у меня есть еще условие, которое попадает под индекс, то норм?

Конечно, проблема только в оптимальности получения данных.
"если у меня есть еще условие, которое попадает под индекс" - что бы индекс работал - надо что бы все условия выполнялись, а не часть)

вроде бы надо чтобы условия попадали в поля индекса с начала и тогда уже индекс будет работать, не обязательно, чтобы прям по все полям был отбор

Что бы индекс полноценно работал - надо что бы поля отбора и выходные поля были в составе индекса.
Будет в итоге вообще индекс использоваться или нет - решает оптимизатор.
Ты можешь написать запрос под использование индекса, а в плане будет обломисто.
Скорее всего это и происходит в техз случаях что указаны в статье

Т.е если у меня есть индекс "поле1, поле2" и я делаю запрос в котом есть условие по поле1, но при этом еще хочу вытащить поле3, то индекс не будет использоваться?

Условие по поле 1 на равенство, а не подобно

Может как использоваться так и нет.
я оба варианта встречал

Так как всех полей нет в индексе то все равно придется за полем 3 лезть в строки основной таблицы. А раз так то СУБД может решить сразу в таблице все искать и вообще не использовать индекс.

Тут вопрос не в том покрывающий индекс или нет, а в том упростит/ускорит он поиск или нет

в примере речь вообще не про индексы, а про "параметр снифинг", кэш планов.
Значение 123% - одно и то же, а передача в запрос - разная. Акцент на этом.

Я хотел понять в чем проблема такого использования
Если я использую это условие "рядом" с поиском по индексу, то вроде все должно отрабатывать быстро
Или тут дело не только в поиске

разве в крайних версия платформы это не пофиксили?

крайние элементы массива - понимаю что такое (первый и последний)
что такое крайние версии платформы - с трудом)

действительно, с учетом того что выходит 2-3 версии одновременно... не подумал

не слышал о проблеме)

Всем привет, подскажите с SonarQube кто знает- есть ли возможность просмотреть весь загружаемый код разработчиками вне зависимости есть в нем ошибки или нет? С таким-же удобным разграничением по проектам и фильтрацией по разработчикам(как в вкладке замечания).