По мотивам Готов поработать падаваном

зависит от запроса

в большей части предпочтительно временные

начни готовиться к эксперту - много нового узнаешь

(3) спасибо, мнение 1С по этому поводу я знаю

Гыы. Если ТемпДБ вынести на RAM диск - тогда - Временные.

(5) а если рамдиска нет?

Главное не допускать того, что temp DB вырастет больше RAM диска.

(6) Тебе 1 гига памяти жалко?

тоже предпочитаю ВТ - их и читать удобнее и тестить да и уничтожать прикольно

(8) мне 16ти то нехватает)

Ну не умеет 1С работать с #table

не хватает*

(12) ты свой голос не изъявил

Временные еще и индексировать можно, только редко когда нужно :-)

были случаи когда замены вложенных на временные снижали время выполнения запроса с 4 минут до 5 секунд

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

(15) круто, хочу пример)

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

Однако мне кажется что есть резерв у временных таблиц.
Подозреваю что на них не распостраняется commit в полной мере.
Это надо проверить. Но сложилось впечатление, что MS SQL 2005 часто (иногда?) оставляет их в памяти и не пишет на диск даже при commit.
Временные ведь...

Так и есть, я вообще наблюдаю нулевую дисковую активность на дисках где лежит tempdb в SQL2k5 - нет активности ни на диске где лог, ни на дисках где лежат данные tempdb. При этом временные таблицы используются.

(17) Так вполне может быть. Я правда на 77 в 1С++ с вложенными получал тормоза, для этого много ума не надо.
Причем на время еще может влиять и другие факторы, как там план запроса Скуль построит.
Один и тот же запрос при разных значениях праметра по разному выполняется. Вроде потестил, нормально, начали работать, поставили период побольше, причем и не сильно намного, и сидят курят. Переписал через временные и стабильно быстро работает.

Счаст придет ascent и скажет, что вы все не попадаете в индекс

для разных субд будет по-разному.

так что тема бессмысленна.

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

(22) Ну Скуль он типа тоже разный бывает.

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

(21) Вы - бессмысленны. Это - по наблюдениям за вашими советами за последнее время.

(23)+ А понял, ты про православный MS .

(22) это оракул и ДБ2 от крайнего нищебродства?

(25) та ты читаешь еще то что после его ника написано? я обхожу обычно

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

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

(27) платную ДБ2 кто нить вообще видел в глаза?

(29) не говори ерунды! лучше почитай Вячеслава Гилева. мс в подмётки не годится ни ДБ2 ни Оракулу

(31) ещё лет 12 назад в ПФР, а что? Под оракул сам писал (тоже купленвый, базы работали на дековских серверах).

(30) не 1с знает, а скуль :)

(30) Как же запись на диск? Вот сожрет SQL всю память индексами и что делать :-) Только RAM. Ну а че, я бы гиг выделил.

Интересно, есть ли настройка SQL принудительно сбрасывать tempDB на диск. Чтобы он точно RAm диск юзал а не висел в оперативке.

Померить бы.

(32) это не ерунда ... это шутка)

(32) Можно ссылку?

В КБ 1с есть очень хорошая статья на эту тему.
В кратце: если большие объемы данных и к ним предполагается частое обращение (допустим больше 1 раза за сеанс) то ВТ без вопросов. Во всех остальных случаях - вложенный будет быстрее.
Разница как уже писали во времени создания таблицы, и построения индекса, если используется.

еще интересный момент, мне один раз поведали историю, как человек не прошел сертификацию именно из-за того, что использовал вложенные запросы

(37) при случае поищу - сейчас уже спать зовут

(40) Спать в 10 вечера ? Окстись!

(38) Я бы добавила - временные быстрее там, где вложенный запрос сложен и MS SQL может неверно выбрать план запроса. А вложенные быстрее там, где либо tempDB лежит в неудачном месте и нагрузка на него велика, либо на простых запросах (просто потому, что план запроса на таких одинаков практически в обоих случаях, а ресурсы на построение ВТ тратятся)

(41) в Кемерово 12-й час вроде

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

(15) - прав на 100% - и у меня были такие случаи. + индексирование в ВТ позволяло существенно ускорить работу запроса.

(43) 3 часа разницы с Москвой. Это я, как Новокузнечанин вам говорю.

(46) Как кто???

(46) забыл значит, что перевели тоже, когда уезжал +4 было

(47) вот и провалился тщательно подготавливаемый миф про Казань

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

Как Новокузнечанин, что не так?

(49) Какая Казань, я родился в Новокузнецке!

(51) Мадам! У вас пол поломался?

С полом все хорошо :-)

И я - не мадам, я H A D G E H O G s! (гордо)

Мадам пока посуду моет - я за нее!

(0) что лучше - яблоки или скорость звука?

(41) младшая отказывается спать пока "папа за компом!", ну вот навскидку: http://www.gilev.ru/1c/81/db2/

(54) что там такое у вас вообще творится!!! Харда взломали детектед!!!!

Легче отлаживать.

1. В виде временных таблиц.


Кста, Е.Гилёв на своих курсах тоже говорит за временные таблицы в подавляющем большинстве случаев.

(9),(59) В чём лёгкость отладки ВТ?

(61) можно сохранить в менеджер ВТ. Это позволяет увидеть в отладчике что там навыбирала та часть запроса +  многократно использовать то что уже навыбиралось.

(58) Все хорошо. Мы уже расцепились и расползлись по своим учеткам.

Субд с большей вероятностью подберет оптимальный план выполнения запроса. Ещё проще отлаживать.

Что лучше декларативное описание выборки или алгоритмическое?
Думаю временная таблица оправдана, если размер ожидаемый выборки в нее будет не космическим и (группа ИЛИ)
- ее подзапрос встречается в запросе более одного раза
- запрос очень сложный, а со временной таблицей он читается легче
- СУБД использует неэффективный план выполнения запроса, а со временной таблицей - эффективный (запрос выполняется быстрее)

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

Также, чтобы редактировать запрос конструктором, стараюсь не делать конструирование запроса из строк вида:

Текст="Выбрать Поле1 ИЗ Таблица1";
Если НекоеУсловие Тогда
Текст=Текст+" ГДЕ Поле2=ИСТИНА";
КонецЕсли;

Делаю так:
Текст="Выбрать Поле1 ИЗ Таблица1 ГДЕ 1 = 1";
Если НекоеУсловие Тогда
Текст=СтрЗаменить(Текст,"1 = 1", "Поле2=ИСТИНА");
КонецЕсли;

(58) нам можно =)

Конечно же ВТ!
Кстати, при ВТ СУБД создает эту ВТ один раз и держит в памяти (потом с ней идут соединения и т.д.). Как с этим обстоят дела при вложенном запросе - он выполняется для каждой строки (что врядли, т.к. тупо) , или же СУБД также пытается оптимизировать его выполнение и он выполняется 1 раз?

практика показывает

(68) план всегда надо смотреть
вот например в этом запросе: v8: Поясните почему не работает запрос?
если бы я использовал ВТ, то ошибки бы не возникало

но более правильно при повторном использовании данных, особенно когда изначально можно сделать выборку из большой таблицы, лучше использовать ВТ
столкнулся с этим еще когда писал запросы на семерке, где все было построено на периодических реквизитах, и _1SConst составлял половину базы по размеру

правда там я использовал тип Table, но здесь он недоступен