В теме v8: Выборка элементов табличной части справочника у меня с одним уважаемым человеком возник спор о том, какой запрос выбора будет эффективнее. Я утверждал, что непосредственный выбор табличной части справочника без явного его соединения с таблицей самого справочника будет работать быстрее на больший объемах данных.

Я провел тестирование и мои слова подтвердились.

Подробности.
Файловая база 1С 8.1. Я завел справочник с табличной частью. У табличной части два реквизита: один строка, второй - ссылка на элемент другого справочника (везде одна и та же).

Я заполнил справочник 2000 элементами и каждую табличную часть этих элементов 500 строками.

Оказалось, что непосредственный выбор ТЧ в запросе работает на таких малых объемах данных уже быстрее на целых 0,5 секунд!

Скриншоты в качестве доказательства (закомментированный код - это как раз код начального заполнения справочников).

http://i056.radikal.ru/1207/5d/afd010d482a9.jpg - непосредственный выбор ТЧ в запросе

http://s51.radikal.ru/i131/1207/89/cbbaab8a0af4.jpg - через явное соединение

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

0.5 сек. все таки мало что б утвеждать что один вариант быстрее от другого.
Попробуй еще так при случае:
Перегрузи комп (или сервер БД) и повтори то самое 3-5 раз для одного варианта, потом опять перегрузи комп(севрер) и опять 3-5 раз другой вариант. Будет точнее сравнение.

Как по мне, так разницы вообще не должно быть :)

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

интересно будет потестить на серверном варианте при гораздо больших объемах

(0) После слов Файловая база, стало не интересно. Тестируй на клиент-сервере. Должно быть одинаково.

(5) многие работают на файловой базе. смысл тестировать на ней определенно есть

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

кому интересно могут пройти в ту тему о которой идет речь v8: Выборка элементов табличной части справочника
и потом составить мнение об авторе этой темы

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

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

и да, тестирование на файловой безусловно очень важно

по сути 1С формирует одинаковые запросы в том и другом случае, для MS SQL
в целом получается удобнее не писать лишнее соединение

(8) Ну зря ты. До десятка бухов файловый вариант тянет. Но лишние секунды там - действительно нах не стОит учитывать.

+(10) но про скорость - это очевидный бред

(8)(11) о чем весь этот бред? автор очевидно ступил и сейчас думает как оправдаться ... на файловой тоже не должно быть разницы

(13) автор тестирует на серверной базе с большими таблицами

(14) автор, иди почитай тему с которой все началось, и покайся

черт, запятая лишняя

хотя нет, наоборот не хватает

(16) не лишняя, наоборот, не хватает

итак, во-первых: (пусть даже взять файловую базу, хоть это и эпик-фэйл)

чтобы говорить о более-менее приближённом к реальности тестировании, нужно сделать примерно так:
делаем 10 тысяч доков с ТЧ с разным кол-вом строк от 50 до 200.
далее перегружаем комп, выжидаем 5 минут, и запускаем цикл на 10000 итераций, в каждом шаге цикла делаем три запроса: по 1-му, 2-му, и по 3-му варианту (1-й - неявное соединение, 2-й - явное левое, 3-й - явное внутреннее).
по каждому варианту вычисляем время отработки запроса и суммируем в трёх переменных. потом делим каждую на кол-во итераций, получаем среднее время выполнения по каждому варианту.

(18) ты не отвлекайся, или ту тему почитай, потом возвращайся

или = иди

(19) да хоть есть над чем поржать в субботу

(13) а в чем он ступил? просто положился на умность движка 1С. по идее платформа в элементарных запросах точно так же должна дорисовть запрос. но как на самом деле хз. 1с не раз свинью подкладывава в очевидных вещах.

(19) ну делай, делай, я что ли за тебя буду делать?
а почему файловая база эпик фейл? на ней тоже можно работать

(23) в ту тему ходил? отличий не видишь?

(22) Субботняя ветка детектид!

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

(24) ты еще здесь и не изучаешь текст запроса из v8: Выборка элементов табличной части справочника
чем он по-твоему отличается от местного первого варианта?

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

(27) да посмотри, у него запросы здесь не те, блин, я один только это вижу?

(29) о наконец-то еще один прозревший)

(29) я думал под эпик фейлом ты это и имел в виду)

(25) хз. может спор о каких то конкретных деталях. я так, о теме в целом.

(33) угу, типичный одинэсник

нравится пообсуждать тему в целом)))

(24) "а почему файловая база эпик фейл? на ней тоже можно работать"  файловая база реализована явно под потребности языка 1С, и не позволяет оперировать над ней скриптами на SQL. так что как там у них всё внутрях организовано - известно одному Нуралиеву (хотя и это не факт).

но, давай, пусть даже на файловой, потесть _по-честному_

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

(36) так сейчас он потестит этот же вариант на серверной и будет убеждать всех что и на серверной такие же результаты)

"ВЫБРАТЬ
   |    РеализацияТоваровУслугТовары.Ссылка,
   |    РеализацияТоваровУслугТовары.Номенклатура,
   |    РеализацияТоваровУслугТовары.Ссылка.Дата
   |ИЗ
   |    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары";

и

ВЫБРАТЬ
   |    РеализацияТоваровУслугТовары.Ссылка,
   |    РеализацияТоваровУслугТовары.Номенклатура,
   |    РеализацияТоваровУслуг.Дата
   |ИЗ
   |    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
   |        ЛЕВОЕ СОЕДИНЕНИЕ Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
   |        ПО РеализацияТоваровУслугТовары.Ссылка = РеализацияТоваровУслуг.Ссылка

на серверной работают одинаково.
Так что да, не быстрее

(39) результаты внутреннего давай

(39) а знаешь почему? потому что пля, сиквел, оптимизировал второй запрос и откинул накуй никому не нужное соединие

(39) ну реально скажи, ну сколько можно тупить? уже ведь не смешно

и да в теме
v8: Выборка элементов табличной части справочника

(41) наоборот, в первом запросе он создал НУЖНОЕ соединение

в теме
v8: Выборка элементов табличной части справочника
andrewks говорил об эффективности явного соединения, так что обоюдный слив, я считаю

(43) сиквел создал?? нуну

(45) а ты не видешь там строчку
РеализацияТоваровУслугТовары.Ссылка.Дата  ?

(44) ты фигуры-то в кармане не прячь, на ничью не выводи, давай результат явного иннер джойна

(39) быстрее быть и не могло. правда пример какой то, не айс.

(46) а, она меня выпала, пропустил, просто в (0) у тебя совершенно другие запросы

(40) а больше тебе ничего не дать?
сначала научись общаться нормально
это относится и к товарищу izekia

(46) 1С генерит, а не сиквел

(49) да, в (0) запросы другие, поэтому я сделал нормальные в серверном варианте

(48) ну да, примеры не совсем удачные, но пусть даже с такими, для начала

(51) тогда сервер 1С их и убирает

(48) что с примером

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

(56) про шапку все понятно уже вроде всем

(50) не хами. ты завёл ветку, ты и доказывай. я вообще всё сказал ещё в той ветке, и добавлять больше нечего

(58) где хамство?

(47) не, иннер будет медленнее, посмотри на план, там просто индекс

(57) ну та запусти ради приличия те же запросы на файловой

(56) 1С не оптимизирует запросы. У них бюджета такого нет, что бы такое написать.

(61) я не спорю, они если и будут различаться, то незначительно.лучше иннер на серверной сделать

(60) + а вот кстати на файловой интересно посмотреть результат иннера

(62) сервер 1С создает план запроса. подозреваю, у субд свой оптимизатор

(62) под оптимизацией я имел в виду оптимизацию текста и отбрасывание явно ненужного куска

(62) да это наверное и не нужно. оптимизатор субд сделает это за них.

(65) план запроса все же у субд, серверу 1С там делать нечего

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

(67) оптимизация на уровне субд зависит от плана запросов, который создаст сервер 1С

(63) посмотри профайлер, если интересно, иннер - это плохая идея

(70) чопростите?

давай ты сначала перестанешь нести чудесную чушь, а потом уже будешь требовать, чтобы с тобой общались уважительно

(72) наверное, он хотел сказать: план запроса, который построит СУБД, зависит от того текста низкоуровневого запроса, который отдаст сервер 1С

(70) с терминами то поаккуратней )) а то щас какашками закидают. или с терминами все точно?

(71) не факт. надо тестить

(74) ну да, веселый чувак ... в целом, если так подумать, то несомненно в какой-то мере зависит ))

(76) что тестить ... в одном кластер скан, в другом два кластерскана и слияние

имеется в виду, что нельзя полагаться на оптимизатор запроса SQL, если сам текст запроса на языке 1С "неоптимизирован"

индекс там у тч, что и естественно

(79) это ты про план запроса на сервере 1С?

(81) про него

(81)(82) О_о  субботница?

Вы ещё вспомните потом про результат обработки запроса - если его не будут выгружать в таблицу, а будут обходить построчно (при этом ещё чего-то выполняя), то может оказаться, что разбив на несколько независимых запросов мы получим ускорение, так как блокировок не будет.

(82) на уровне конструктора запроса может быть)

(84) мощно. такое было да? наверное это было весело.

(84) а если блокировки начнутся как раз на момент обхода?

(84) про это речи не идет

(79) + (82) текст оптимизируется только в голове у автора, и соответственно в коде, даже конструктор запроса не помогает в этом прекрасном деле, вполне пропустил такое:
ВЫБРАТЬ
   ПользователиКонтактнаяИнформация.Тип,
   ПользователиКонтактнаяИнформация.Представление
ИЗ
   Справочник.Пользователи.КонтактнаяИнформация КАК ПользователиКонтактнаяИнформация
       ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Пользователи КАК Пользователи
       ПО ПользователиКонтактнаяИнформация.Ссылка = Пользователи.Ссылка
и сервер 1С тоже не помогает оптимизировать текст запроса:
SELECT
T1._Fld422RRef,
T1._Fld424
FROM _Reference49_VT420 T1 WITH(NOLOCK)
LEFT OUTER JOIN _Reference49 T2 WITH(NOLOCK)
ON (T1._Reference49_IDRRef = T2._IDRRef)

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

собственно, основной момент: конспирологический. нет уверенности, что 1С протранслирует любой сложный запрос с неявными соединениями идентично аккуратным явным соединениям

(90) ну да, я пробовал простенькие, но там все корректно, думаю буду переходить на такой вариант

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

(92) "На самом деле - очень интересно, что получит запрос, если в момент его исполнения мы поменяем какой-то элемент справочника. "
Все что угодно :). Модно ведь использовать ДЛЯ ИЗМЕНЕНИЯ

(90) А как она его ещё может выполнить ? Табличная часть - это соединение один на много и как ни крути, его придётся как-то выбирать.

(93) не отвлекайся, теперь меня интересует что ты имел в виду под оптимизацией запроса на сервере 1С

(95) где я говорил про оптимизацию за сервере 1С?

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

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

(96) план запроса, простите

(70) + (82) ты про какой план запроса?

(97) А почему они тогда запрещают писать запросы напрямую в SQL, где можно ещё и план выполнения задать.

(99) имелся в виду текст, сгенерированный сервером 1С, который не всегда просто берет и копирует текст, написанный в модуле

(101) потому, что тогда 1С начнёт работать сразу очень быстро, и ихние обновления никому нафиг не нужны будут :)

(102) это не план запроса, а просто сгенерированный запрос, аккуратнее с терминами

(103) лол)

(101) потому что 1С - это орм

в 9.0 думаю появится такое

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

(108) в целях анализа узких мест, а не работы с субд

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

(110) это вообще зло, на мой взгляд

да и простите, в (41) погорячился

(111) Просто обсуждать скорость выполнения SQL-запроса, когда в реальности происходит сначала передача запроса на сервер, потом трансляция запроса из 1С в SQL, выполнение его SQL-сервером, передача результата обратно (чаще всего по сети), потом выдача результата запроса на клиента, где информация уже будет отображаться.
Так что нужно анализировать весь путь.