Как кошернее: получать значения реквизитов через точку, вызывая неявное соединение или же явно прописывать все необходимые соединения?
Например (простенько): В документе есть реквизит Контрагент, тип справочник Контрагенты. У справочника Контрагенты есть реквизиты ИНН и КПП. Как лучше:
1.Выбрать Док.Контрагент.ИНН ИЗ Документ.МойДок
или
2.Выбрать Контрагент.ИНН ИЗ Документ.МойДокумент КАК МД Левое соединение Справочник.Контрагенты КАК МК ПО МД.Контрагент = МК.Ссылка
?
Если сие обсуждалось, можно дать ссылку ))

Пофиг

дак это одно и тоже

Явно прописывать.

Чтобы это понять нужно воспользоваться профайлером.

Я в принципе так же считал. Но С.Арутюнов из УЦ1 на одном из последних курсов сильно меня удивил, сказав что правильный, с точки зрения оптимальности - только вариант 2. И типа на Специалисте с вариантом 1 можно серьезно погореть. Специалист меня не сильно интересует, а вот оптимальность... Объяснение было таково, что все неявные соединения для интерпретатора на сервере - зло.
(3) Во-во, почему?

а вдруг Док.Контрагент ТипВсеСсылки?

(5) Чтобы тупая 1с не строила из себя оптимизатора, у нее это плохо выходит)

(6) Т.е. интерпретатор именно на это расчитывает, цепляя все возможные таблицы? Не верю ))
А защититься - ставь выразить, если такое в принципе возможно

(6) Это проблемы индейцев.

(6) Тем более есть ВЫРАЗИТЬ(), вместо всяких там заумных левых соединений.

(7) Риторический вопрос конечно, но зачем же тогда такую возможность дали? Я когда только начинал писать в восьмерке, по sql-му строил запросы, т.е. вариант 2. Потом расчухал, что можно использовать 1 вариант, и по тихоньку отказался от более трудоемкого варианта. Теперь выясняется, что 1с даже в таких простых ситуациях плозой оптимизатор ))
Прям абидна, да?1!

(11) Надо хорошо изучить 1С и обидно не будет.

(11) Незнаю, я как увидел разыменования в восмерошных запросах мне дурно стало, превратили язык запросов в какую то херомантию, которая еще и тупит на ровном месте.

(11) любой ORM работает неоптимально, но удобно.

(11) ага, еще Неопределено ввели

(4) да не будет тебе в тягость :)

Я по привычке написания запросов в sql все явно указываю, целее будет.

1С пишет запросы оптимально.

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

(9) да я вообще мимо проходил, чО

(18) что оптимальней INNER или LEFT JOIN, если известно, что результат одинаковый? (например ссылка NOT NULL)

Табличка, в составном поле которой могут быть и Контрагенты и Организации. Как писать запрос? Пройтись по табличке 1 раз, чтобы понять, какие есть там есть по факту типы значений и построить оптимальный запрос с левым соединением по нужным табличкам, либо сразу соединить все таблички? 1С выбрали 2 вариант.

(21) По логике то Left, по факту - не знаю.

(23) вот я слышал оба мнения, правда на разных СУБД

+(24) да, важно - поля индексированные

(0) помница посещал выездные курсы 1С (тогда ток-ток 8.2 в массы выходила). Там задавали похожий вопрос. Специалист 1С ответил так:

Сперва 1С-разработчики рекомендовали пользоваться вариантом "1" (через точку) - типа очень удобно стоить запросы, все ништяк, все тип-топ. Но сейчас они же говорят ,что более оптималь делать по методу "2" через конкретные соединения, чтобы СКЛ-запросы были более конкретными и точными...

буду пользоваться вариантом 1, пока явно не понадобится добыть эти 0.00005msec дополнительного прироста производительности. И идут они в жеппу, эти разработчики.
На кой хрен тогда вообще предметная ориентированность платформы и программирования в ней, если мы будем явно эти сцаные соединения писать.

(27) скажи это разработчикам ОРАКЛА :)

(27) +500

(26-27) Я вообще не вижу откуда разница может появиться. Вот поясните мне, уважаемые гуру, если в тексте есть разъиенование - то 1Ска при построении sql запроса включит необходимое количество соединений сама. Тоже самое она сделает, когда я сам пропишу соединения. Т.е. код, который отправится в СУБД - будет один и тот же, так почему вариант 1 - не оптимальный?

(25) Встречный вопрос.
Почему в УПП СЛУ решаются методом простых итераций при расчете себестоимости выпуска.

(28) 1С <> оракл, по этому пусть разработчики вприпрыжку несутся в указанном направлении со своими рекомендациями огондошивать на корню сопровождение кода этими простынями запросов

(30) Это надо спросить у Попытка1С

(30+) Единственно, что в голову приходит, что если в запросе будет например Док.Контрагент.ИНН, Док.КОнтрагент.КПП, и еще несколько полей из КОнтрагента, то 1С может сдуру завигачить столько соединений, сколько полей в запросе, вместо одного. НО это уже вопрос к разработчикам.

"то 1Ска при построении sql запроса включит необходимое количество соединений сама."

я лично сталкавался когда при указании через точку 1с джонила все что можно и все что нельзя, причем какого черта хрен поймешь, поэтому нафиг.

(27) Концентрированная истина.

(35) Составной реквизит, или ЛюбаяСсылка (адскэй кошмар, вообще такой тип запретить)

(35) однако....
тогда стоит учитывать

(34) Фигня. Вот такой запрос будет

SELECT
T2._Fld19,
T2._Fld20
FROM _Document17 T1 WITH(NOLOCK)
LEFT OUTER JOIN _Reference16 T2 WITH(NOLOCK)
ON T1._Fld18RRef = T2._IDRRef

(38) Щас пример попробую найти.

Просто 1сники ленивые не хотят думать, легче точку поставить и все дела)

(41) скроее это следствие того, что кто-то в транслятор запросов сервера приложений костылей из быдлокода понаколотил

(41) а чо тут ещё думать нада? О.о

(39) В таком случае я не могу представить случая, когда будут цепляться лишние таблицы, и появится разница между 1 и 2.
(40) Ждемс ))
У меня через стол сидят матерые sql-ки. Поначалу они сильно стебались над запросами и кодом на русском, но когда я им показал запрос с раъименованием, они как-то притихли. )) Видать завидуют черной завистью.
На самом деле - есть мнение, что истина в (27). Может где-то и будет ИЗМЕРИМАЯ разница между 1 и 2, но в 99.(9)% случаев - она насколько мала, что ею можно смело пренебречь

(44+) А прописать все необходимые соединения в здоровенном пакетном запросе - ну его. Пускай 1С жужжит

(44) Матерые sql-ки, 1сникам в принципе завидовать не могут)) имхо

(44) Утешь их тем, что тут нет приведения типов, выполняемого кода, временных таблиц в памяти и много чего еще.

(47) Зачем? ))

Сорри, может не в тему: прежде чем говорить об "оптимальности" - надо вспомнить про РЛС. Кто знает как оно работает при "явном" и "неявном" соединении? Профайлер? :)

(44) Спроси их, что быстрее inner или left join.

(31) а каким надо?

(51) Гаусса-Зеделя. Не?

Зейделя.

(52) покопался...
ну... не знали они про него - взяли первый какой вспомнили

http://www.sql.ru/forum/actualthread.aspx?tid=523444

(54) Они взяли самый забавный метод.

Приближенный. Он конечно будет линейно сходиться, если он будет вообще сходится. А вот метод Гаусса имеет решение всегда.

(57) метод Гаусса не надо путать с методом Гаусса-Зейделя
первый очень тяжелый в вычислениях, второй хорош именно для разряженных матриц, но тоже может не сходиться

Хотя нет, и Гаусса Зеделя - тоже приближенный.