Вот ведем спор с коллегой по поводу того, что если в запросе используется большое количество левых соединений (есть основная таблица, и к ней присоединяются левым соединением по некоторым полям другие таблицы), то по его мнению нужно запрос раскидывать на множество наборов данных и соединение делать через "Связи наборов данных" - это удобно! Именно удобно.
Я же как-то не сторонник из-за слова удобства перекочевывать на наборы данных вместо левого соединения.. Но и нет весомых доводов сказать, что 5-10 наборов данных хуже чем левое соединение..
Какие аргументы (какие показатели сравнения) могут быть ЗА наборы данных или ЗА левое соединение?

Это религиозный вопрос.

мс скл может индекс подходящий использовать.1с уж не может

(1) Когда две религии конфликтуют между собой, побеждает сильнейшая?

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

(2) При простом связывании наборов данных (без применения параметров), СКД получает все данные из БД за одно обращение?

(0) Ну попробуйте соединить строки левым соединением, чтобы в одну ячейку вывелось в отчете. Все зависит от задачи, главное понимать как оно работает.

(3) Побеждает наука.
Делаешь и так и так. Смотришь планы, получившихся запросов в скуле. Если нет разницы, то ничья.
Но т.к. везде левые соединения, то скорее всего ничья.

(6) Выбор когда ... тогда ... иначе ... конец

(6) Та оно-то понятно, что при связи наборов данных вывод может быть разный..
Я подразумеваю, что задача одна и она может быть достигнута как простым левым соединением одним запросом в СКД, либо же путем соединения нескольких наборов данных. И вывод при этом будет идентичный в обоих случаях.

(7) Как может не быть разницы, если в случае наборов данных будет минимум 2 запроса, а при левом соединении - 1?

(4) Важное условие спора: все на СКД.
Только в 1 случае делается в одном наборе всё левым соединением.
Во втором случае соединение путем связи наборов.

(10) А есть инфа подробная об этом? Опытным путем анализировали план запросов? Я просто этого не делал. Но тоже есть предположение, что при левом соединение будет 1 запрос, а при связи наборов - несколько..

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

(12) запусти профайлер

(0) Смотри сюда СКД. Связи наборов данных. ЕСТЬ NULL если хочешь иметь неожиданные результаты пользовательских отборов, используй связи наборов данных )

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

(15) Спасибо, что-то было такое у меня давно..

+ с множеством наборов данных надо настраивать поля аккуратно, есть вероятность два одинаковых по смыслу поля назвать по-разному. Или наоборот, дать одинаковое название (в одном наборе не получится).

Соединение в запросе быстрее.

Что за вымышленный коллега? Пусть в эту ветку придет и спорьте тут

(18) Это к чему?

(19) К первому вопросу наверное

(20) Никакой содержательности, точно не к первому.

Что-то ты не понял походу. Какая смысловая нагрузка от упоминания тобой какого-то коллеги?

(22) Я в (19) и спросил об этом.
Это вступление, с чего возник мой вопрос. Спор закончили, теперь уже самому хочется разобраться, стало интересно

(12) Это очевидно следует из архитектуры СКД:
1) В настройках соединения ты задаёшь не только связи, но ещё параметры, когда поле из одного запроса передаётся в качестве параметра другого запроса. Поэтому там возможны всякие выверты типа остатков на каждый день или срезов последних на каждый день, которые в запросе тета-соединениями получаются.
2) В макете компоновки данных, когда ты видишь "действительные" запросы, которые СКД шлёт - они тоже не соединены никак и лежат разными запросами.
3) Ты можешь спокойно соединять таблицы разных СУБД, полученные запросами к внешним источникам данных через связи наборов, но не можешь делать это в запросе (что вполне логично - ведь это разные СУБД!)

Всё это свидетельствует однозначно о том, что работа с наборами происходит в контексте сервера приложений 1С, а не конкретной СУБД.

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

(25) Да, можно опустить.
Считаешь это лишней информацией?

Конечно, ведь от истории возникновения вопроса его суть (и ответ) не меняются?
И за тобой вроде такое не в первый раз замечено. И это еще не понабежали любители анекдота про "своего друга" )

(24) Очень сильный ответ!

(27) Наверное не меняется. Возьму на заметку

Мелко плаваете в СКД...

(29) Поделитесь-ка, что там в глубоководье?

по мне так старая добрая консоль запросов - для отладки самое то, следовательно я за один набор данных, по возможности (всякие там собственные иерархии не в счет)

плюс опять таки в одном наборе можно использовать
выбрать ... поместить ВТ1 индексировать по ПолеСвязи;
выбрать ... поместить ВТ2 индексировать по ПолеСвязи;
выбрать ... ВТ1 левое соединение ВТ2 по ВТ1.ПолеСвязи = ВТ2.ПолеСвзяи;
с точки зрения оптимизации выполнения запроса такая индексация рекомендуется

что там происходит под капотом с индексацией при связи двух наборов - ХЗ

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

контраргумент: правда у Хрусталевой в самом начале приводится пример, почему лучше использовать 2 набора данных вместо одного с левым соединением...
но вот только на практике ни разу не удавалось написать отчет с задвоенными данными

(0) запустите с коллегой профайлер и сами все увидите

(31) Благодарю за раскрытие.
По прикладному смыслу использование двух наборов вместо одного для избежания задвоенных данных:

Вы попробуйте сделать левое соединение таким образом, чтобы для каких-нибудь строк левой таблицы было сопоставление нескольким строкам из правой. И то же самое сделайте установкой связи двух наборов.
При связи наборов в группировке отчета по полю основного набора, данные "не задвоятся" (несмотря на то, что одной строке основного набора установилась связь нескольким строкам дочернего набора).
А при левом соединении данные "задвоятся".

(33) А какая строка (из "задвоенных") попадает в отчет?

(34) Если ресурсом будет выражение, которое вычисляется по полю левой таблицы, тогда этот ресурс и "задвоится" при группировке по полю левой таблицы.

Так ты пишешь что в СКД не задвоятся данные, а в запросе задвоятся

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

Все это относится к СКД. (36)