Имеем:
Документ "Док".
В "Док" есть ТЧ "Изделия".
В "Изделия" есть реквизит "Изделие" - ссылка на спр.Изделия.
У документа индексация по "Изделие" включена.

Изделие может быть только в одном из "Док".

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

1.

ВЫБРАТЬ
   ДокИзделия.Ссылка
ИЗ
   Документ.Док.Изделия КАК ДокИзделия
ГДЕ
   ДокИзделия.Изделие = &Изделие

2. ВЫБРАТЬ
   Док.Ссылка
ИЗ
   Документ.Док КАК Док
ГДЕ
   Док.Изделия.Изделие = &Изделие

2

Первый думаю конечно же

(1) Почему? Там же будет соединение с ТЧ вроде?

(2) а вариант 2 разве рабочий?

(2) Да

Имхо так правильнее:
ВЫБРАТЬ РАзличные
   ДокИзделия.Ссылка
ИЗ
   Документ.Док.Изделия КАК ДокИзделия
ГДЕ
   ДокИзделия.Изделие = &Изделие

(4) Рабочий. Но мне кажется более медленный. Чисто интуитивно. Поэтому вопрос и возник.

(6) Зачем? Изначально известно, что Изделие только в одном из Док.

(6) так не бывает :)

Имхо, вариант 2 плох. Там соединяться будут две таблицы. Даже не знал, что такой вариант может быть.

(8) Документ известен?

(10) В первом варианте разве не будут две таблицы соединяться? По-моему тоже будут.

(11) нет. его и надо найти

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

Тут даже обсуждать нечего, однозначно 1й вариант. Во втором мы имеем разыменование, неявное соединение с еще одной таблицей, Невозможность перебора таблицы по индексу - явный фэил в общем. Это кстати элементарно проверить трассировкой MS SQL

(13) Тогда и вопроса не стоило задавать,

(16) Это почему же? Вопрос в том и был - каким запросом быстрее Док найти зная Изделие.

(15) База файловая. Скуля нет.

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

(12) С фига ли?

(17) Судя по твоим вопросам - ты в восьмерке 5.5 лет.
Вопроса не стоило задавать.

(12) в первом запросе напрямую обращение к таблице ТЧ будет, никаких соединений

(22) т.е. 1С возьмет таблицу ТЧ, наложит фильтр по "изделие" и с результата получит ссылку. Так?

а во-втором запросе как будет?

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

(24) грязное чтение надо жестко включать на СУБД, по умолчанию будет read committed. Если СУБД версионник, то будет получена версия на начало транзакции, но это не есть грязное чтение.

(21) Да вот что-то ступор какой-то с этими двумя вариантами. :) Вроде и понимаю, что первый запрос по всем показателям лучше, но второй тоже возможен, а как он отрабатывается не могу понять.

(25) А разве грязное чтение - это не чтение из БД по состоянию БД на момент чтения записи?

(23) СУБД будет обращаться к таблице ТЧ документов. Она посомтрит индекс и оценит, сколько строк результат стоит ждать. Раз ты говоришь там 1 док только, то будет составлен план запроса переборки ТЧ через индекс.

(27) Грязное чтение - это когда внутри одной транзакции два селекта с одинаковыми отборами выдадут разный результат.

(23) второй запрос будет через соединение двух таблиц по ссылке. Ссылка тоже проиндексирована, но запрос к двух таблицам даёт меньше шансов составить максимально эффективный способ перебора оптимизатору.

А чего гадать? А протестить призводительность - проблема?

(31) Проблема - База пустая :)
(30) Ну и всё тогда. Вывод прост: первый запрос быстрее и правильнее. потому что используется только 1 таблица базы данных.

(28) Вот не факт

(28) Далекоооо не факт

(33,34) Объясни :)

(31) Дело не в гадании, а в понимании работы 1С с такими запросами.

(28)
Помогите понять индексы MS SQL

пост 13, 18 и вывод в постам 36, 53

(34) Что не факт? Скан индекса? Конечно не факт, от статистики будет зависеть. То, что будет скан 1й таблицы - факт.

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

Я думаю, он прочитает то, что есть в таблице.

Хотя нет, я перепутал

При годной статистике, при высокой селективности (как у меня в примере (37)) - будет TableScan, при низкой - IndexScan

У автора будет IndexScan, так как записей мало (1-а, изделие одно же)ю

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

(42) Ну в общем я про это и говорил вроде

(44) Не, я конечно рад, что вы договорились. Мне по-русски объясните? Ну или скажите где почитать. Как-то далек я оказался от прямой работы с таблицами в SQL, слишком смутно понимаю о чем вы договорились :)

(43) А я почему-то думаю, что на SQL и управляемых блокировках 1с в запрос попадут существующие в таблице записи и записанные на момент чтения.

(45) Мне кажется, ты - троллишь?

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

(47) Не. Вопрос на самом деле был. Выводы я сделал - первый запрос правильнее по причине работы 1С (как СУБД, ибо база файловая) с 1 таблицей данных. Но, смотрю, вы тут уже глубоко стали копать. Я с этой стороной не сталкивался настолько глубоко, вот и стало интересно. Смутно понимаю о чем речь - насколько общих знаний по СУБД, но такие детали...

(49) Воооот это почитай.

Именно эту статью я бы преподавал в универе студням до потери пульса.
http://www.sql.ru/articles/mssql/03013101indexes.shtml

(48) Друг, мне неинтересно что ты там думаешь. Версионник отдаст данные на начало транзакции, MS SQL наложит блокировку на запись до конца транзакции записи - это суровая правда жизни.

(51) а разве блокировка на запись - это не просто флажок в строчке таблицы?

(50) За ссылку спасибо. :)

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

(54) есть несколько режимов чтения

и вообще разве транзакция сама по себе что-то блокирует?

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

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

(55) дык вот на курсах, лично Габец мне говорил, что в режиме управляемых блокировок одинес читает в запросах то, что есть в таблице. Ей плевать на то, что в строке таблицы SQL установлен флажок "заблокировано".

(58) Ты жестоко ошибаешься. СУБД и без 1С обеспечивает заданный уровень изоляции транзакций. Просто когда 1с в автоматическом режиме, этот уровень более высокий. Выполнить грязное чтение в управляемом режиме блокировок не получится. Read Committed пишется в мануале к 1с как уровень изоляции, использующийся для всех СУБД, кроме файловой, в управляемом режиме. Это не выдумки - это как бы факты.

(58) ну и блокировка - она как бы в менеджере блокировок хранится, а не в СУБД, не понимаю про что ты говоришь.

(59) а еще на курсах мне объясняли, что если конфигурация работает в полностью управляемом режиме, то без применения управляемых блокировок, запрос читает то, что ему выдает СУБД.
Т.е. уровень изоляции транзакий опускается до уровня СУБД.

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

З.Ы. Это если не писать блокировки.

(61) Друг.
Хватит.
Уровень изоляции транзакций опускается до базового уровня для СУБД. Этот уровень - read committed. Далее заисит от того, как СУБД его обеспечивает. MS SQL накладывает исключительные блокировки на подвергшиеся update записи. Я не понимаю, что за желание козырять какими-то курсами, когда можно трассировкой всё увидеть вживую.

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

И если ты будешь строить отчет, а в это время по данным отчета пройдут изменения, то ты получишь мешанину.

(17)[Это почему же? Вопрос в том и был - каким запросом быстрее Док найти зная Изделие.]
ты будешь удивлён, но в типовой это сделано критерием =)

(64) Удивлен. Можно подробней :)

(65) открой УПП и увидишь как по спецификации находится изделие и наоборот =)

(63) Открой иногда профайлер, ага

(63) Когда ты пишешь
БлокировкаДанных.Заблокировать();

1С переводит SQL из READ COMMITTED в REPEATABLE READ на период транзакии.

(66) Под рукой нет, а качать сейчас не охота. Может логику так - на пальцах можешь рассказать?

(63) Ты хочешь отстраниться от того, что творится в SQL, а это невозможно.  SQL будет выдавать не всё подряд, а в соответствии со своим уровнем изоляции транзакций. И мешанина в отчете, естественно, возможна - insert, например, сработает без каких-либо проблем и блокировок.

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

и эту связь 1С хранит в отдельной таблице

и эта таблица доступна языку запросов

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

(68)  БлокировкаДанных.Заблокировать() - вроде как это установка только для собственного менеджера блокировок и на sql не влияет, там  READ COMMITTED