Господа.

Имется отчет.
В нем два набора данных - оба запросы.
Которые соединяются на закладке "Связи наборов данных"

Прошу подсказть в чем смысл такого соединения если вместо двух запросов все это (включая соединение) межно сделать в одном запросе.

Прошу поделится соображениями.
Спасибо

Типа так удобнее, передаем параметр в виртуальную таблицу.

На самом деле выходит банальный запрос в цикле

(0) Если в запросе - выполняется на субде. Если в компоновке - то на сервере 1с.

(2) ну не факт, наверное может и в СУБД растранслировать
как в LINQ - место выполнения зависит от конкретной реализации

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

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

(3) Какой linq, акстись, Аксинья, это же 1с...

(2) На СУБД - должно быть быстрее - но то он серрвер - запросы обрабатывать.
(3) А в чем неудобство доп. свойства обычным запросом выводить?

(5) А в чем неудобство доп. свойства обычным запросом выводить?

(0) Ты призываешь к гаданию на кофейной гуще, все зависит от конкретного случая.
Вдруг там разработчик свою иерерахию делает?

(9) А что в запросе нельзя кауюто иерерхию делать какую в СКД можно?

(6) че сразу обзываться

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

(12) если нужно вывести пару свойств, то можно без проблем через левое соединение в одном запросе сделать, тупо присоединив табчасть со свойствами, где в связях отобрать по нужным свойствам.

(13) Зачем левое соединение?

(14) а почему бы и нет?

(15) А так:
Запрос по характеристикам

(15) Левое соединение это тормоз. Если можно без него, то нужно без него.

Для пары свойств точно никакие соединения не нужны.

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

(17) смотри. К примеру у тебя есть результирующая таблица с номенклатурой. Нужно к этой таблице добавить колонку с одним определенным свойством. Чем это будет тормознутее, если я левым соединением к основной таблице прицеплю таблицу дополнительных свойств и в связи укажу номенклатуру и нужное свойство?

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

(0) Используют для построения иерархии не иерархических данных, например.
т.е. есть произвольные данные не справочники и необходимо выстроить иерархию по каким, то колонкам.
На СКД это делается удобно.

(21) Ссылку в (16) почитай. Там по времени проверили что быстрее и на сколько.

(23) а если нужны ВСЕ данные из результирующей таблицы?

PIVOT тебе в помощь.
Он отработает ещё быстрее - когда его в 1С сделают :-).

(12) Характеристики, нет?

(24) круто так взять и обрезать весь результат) В общем в разных случаях используются разные соединения. Мне в большинстве случаев нужно сохранить первую таблицу полностью и добавить данные из второй. Поэтому и левое соединение. А по поводу динамически вывода всех свойств отдельной колонкой я так примера и не увидел в одном запросе. Через наборы это очень просто делается.

(24) Что значит все?

(26) Да, но это слишком просто видимо )

(28) У тебя к примеру 20 дополнительных реквизитов в номенклатуре. Нужно всех их вывести в отдельные колонки в отчете в рядом с номенклатурой.

(27) Читали в ссылке (16) все посты, включая пост 28?

(26) Не знаю почему. Меня всегда удивляет использование левого соединения везде где нужно и не нужно.

(32) я же уже объяснил, что часто нужно сохранить первую таблицу без изменений, вот поэтому и левое.

(30) Это количество же конечное? Всего 20-ть.

SELECT
     [1] AS А1
    ,[2] AS А2
    ,[3] AS А3
    ,[4] AS A4
    ,[5] AS A5
    ,[6] AS A6
FROM  
    data as t
pivot
( max(t.aa)
for t.npp in ([1],[2],[3],[4],[5],[6])
) as pvt

Как тут видно текст запросе не сложно динамически на любое количество построить....

(33) Еще раз пост 28 по ссылке в (16). Не нужно левое соединение. Достаточно объединения.

(34) это не конечное количество, любой менеджер может добавить свойство и оно должно добавиться в отчет автоматом. Проще говоря динамическое количество колонок

(34) могу на почту скинуть пример с наборами где это реализовано для ут11, если интересно

(0)
Соединение наборов и левое соединение это не одно и то же

(36) Если СКД, то чем не устраивают характеристики?
Если SQL, то прописывать в любом случае - динамическое количество колонок - значит динамический текст запроса.

(38) ИСТИНУ говоришь :-)

(33)
Левое соединение не всегда оставляет левую таблицу без изменений. Частенько дублирует строки в этой самой левой таблице.

(39) Я с характеристиками толком не работал. Да можно их на вкладке указать, а далее без проблем фильтровать отчет по свойствам, но как это поможет динамически создавать колонки без явного указания связи характеристик. Вот пример с оф сайта: https://its.1c.ru/db/metod8dev/content/1795/hdoc
Кусок с примера (и да там левое соединение):
ЫБРАТЬ
РасходнаяНакладнаяСостав.Номенклатура КАК Номенклатура,
ПРЕДСТАВЛЕНИЕССЫЛКИ(РасходнаяНакладнаяСостав.Номенклатура) КАК НоменклатураПредставление,
ДопСвойства.Свойство КАК Свойство,
ДопСвойства1.Свойство КАК Свойство1
ИЗ
Документ.РасходнаяНакладная.Состав КАК РасходнаяНакладнаяСостав
  ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ДопСвойства КАК ДопСвойства
  ПО (ДопСвойства.Номенклатура = РасходнаяНакладнаяСостав.Номенклатура
    И ДопСвойства.ВидСвойства = &П)
  ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ДопСвойства КАК ДопСвойства1
  ПО (ДопСвойства1.Номенклатура = РасходнаяНакладнаяСостав.Номенклатура
    И ДопСвойства1.ВидСвойства = &П2)

Вот я и пишу, если свойств будет 50, так же будете все 50 прописывать? Можете мне скинуть простой пример, где с помощью характеристик выводится динамически колонки со свойствами для номенклатуры?

(42) Это плохой пример :-)

(43) другого не нашел)

(43) тем и хороши наборы, что они в цикле все это дело склепают, как тебе надо и при этом минимум кода в запросе

С диска ИТС "
ВЫБРАТЬ
РасходнаяНакладнаяСостав.Ссылка КАК Документ,
РасходнаяНакладнаяСостав.Номенклатура,
РасходнаяНакладнаяСостав.Количество,
РасходнаяНакладнаяСостав.Цена,
РасходнаяНакладнаяСостав.Сумма,
РасходнаяНакладнаяСостав.НомерСтроки
ИЗ
Документ.РасходнаяНакладная.Состав КАК РасходнаяНакладнаяСостав
{ХАРАКТЕРИСТИКИ
ТИП(Справочник.Номенклатура)
СПИСОК ПланВидовХарактеристик.ВидыДопСвойств
ИДЕНТИФИКАТОР Ссылка
ИМЯ Наименование
ТИПЗНАЧЕНИЯ ТипЗначения
ЗНАЧЕНИЯ РегистрСведений.ДопСвойства
ОБЪЕКТ Номенклатура
ХАРАКТЕРИСТИКА ВидСвойства
ЗНАЧЕНИЕ Свойство }

Запрос, который сгенерирует компоновщик макета компоновки данных, будет выглядеть следующим образом:..." далее из (42)

Если компоновщик генерирует такой запрос, то это очень плохо.
Почему - это работает не быстро, по сравнению с другими вариантами.

Теперь понятно почему чуть что JOIN лепят. Так на дисках ИТС учат иногда. :-)

На дисках ИТС много очень полезной информации, но бывает и так.

(46) На самом деле, надо посмотреть какой запрос при работе с характеристиками приходит на SQL.
У меня есть огромные сомнения, что приходит запрос в (42). Скорее всего так написали, что бы была понятна суть. А прилетает, скорее всего, что-то типа как в (34).

+ к (48) Если без PIVOT, то хотя бы запрос в (16). Он быстрее.
Для DB2 прилететь должен запрос в (16) максимум. В DB2 ранее не было PIVOT.

(46) фишка в том, что фигурные скобки раскроются только для тех свойств, которые будут использованы в итоговой компоновке. а таковых на практике не слишком много

(50) При динамическом построении текста запроса так же.

(4) Юзер знать не знает про соединения вообще, что там неожиданного может быть? Левое превратится во внутреннее, ну так от фильтра это и ожидается.
(42) Покажи простой пример, а то я не догоняю о чем спор идет

(42) Простой пример - в любой типовой, где от ссылки через точку выводятся значения доп. реквизитов.
Например, для Товаров в УТ.  Единственно, там Характеристики прописаны в самом объекте метаданных, а не в запросе, но там несущественная разница.

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

+ к (51)
Фигурные скобки, это и есть динамическая часть построения текста запроса, которая строится в зависимости от...

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

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

Тьфу. "Упростить запросы".