Немного о временных таблицах в 1С или кто на кухне хозяин?

Публикация № 1020673

Администрирование - Оптимизация БД (HighLoad)

-2
Я не люблю временные таблицы. Не люблю не потому, что мне непонятно их назначение, и не по особым религиозным убеждениям. Я не люблю их потому, что они чрезмерно активно и необоснованно используются разработчиками 1С, делая большинство конфигураций практически непригодными для использования в сложных информационных системах с большим количеством регистрируемых операций, обрабатываемых данных и пользователей. Хотя, анализируя код типовой, к примеру, зарплаты, она и в небольших системах работать не должна. Я вкладываю в понятие «Работать» - бесперебойную работу без сбоев и отказов.

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

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

Итак, наш отдел информационных технологий - ресторан.

Посетители этого ресторана - сотрудники, запросившие в виде порции "блюд" необходимую им информацию из 1С.

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

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

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

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

- Основная часть продуктов, которые работники берут в кладовой (информация в базе хранения данных), перед попаданием в блюдо должна обязательно помещаться в зону временного хранения (в таблицы системной базы tempdb). Такова методика 1С для приготовления лучших и самых вкусных блюд. Объяснение простое - только так наш шеф-повар может удобно контролировать, оценивать и улучшать процесс. И действительно, ведь гораздо проще контролировать компоновку блюд из небольшого стеллажа, где в зоне обозрения удобно расположены все необходимые ингредиенты. В противном случае необходимо изучать устройство кладовой, выстраивать маршруты работников, придумывать новые способы извлечения и компоновки продуктов - зачем изобретать велосипед? Ведь все давно придумано и описано умными и уважаемыми мастерами с безупречной репутацией. Лично я предполагаю еще одно возможное обоснование, из области виноделия: хороший коньяк - выдержанный коньяк, это же всем известно.

Есть, конечно, и некоторые минусы – работникам нашей кухни слишком часто приходится бегать в кладовую, ведь, хотя в основном они готовят для временного хранилища сразу смесь ингредиентов, иногда, ради удобства шеф-повара им приходится бегать на склад за каждым продуктом отдельно. Но не стоит о них тревожится - они у нас очень быстрые, натренированные, прекрасно знают, что и как хранится в основной кладовой, а также то, каким образом лучше всего это достать. Они бы могли даже готовить блюда быстрее, собирая и компонуя все необходимые ингредиенты сразу в кладовой, не посещая зону временного хранения. Но разве полученная выгода может сравнится с неудобствами, с которыми придётся столкнуться нашему шеф-повару?

В общем, работа на нашей кухне кипит. Шеф-повар раздает команды, работники шуршат и наши немногочисленные утренние посетители получают заказанные блюда в ожидаемые сроки. Все довольны и счастливы.

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

А на кухне коллапс. Потому, что исполнительные работники продолжают четко выполнять распоряжения шеф-повара, перетаскивая требуемые для заказанных блюд ингредиенты из кладовой в зону временного хранения. Вот только в этой зоне сейчас полный хаос, сотни работников всех мастей пытаются пробиться к стеллажам хранения. Кто-то для того, чтобы поместить в заветную ячейку хранения очередную порцию продуктов из главной кладовой, кто-то, чтобы забрать помещенные ранее продукты и приготовить, наконец, заказанное блюдо. По головам, орудуя локтями и рассыпая ругательства. Ну, тут я немного приукрасил. Молча они ломятся и очень целеустремленно. Вот какому-то счастливцу, наконец, удалось вырваться из общей толчеи. Он мгновенно приготовил заказанное блюдо и передал заказ официанту, тот ринулся в зал, но заказчика в гудящем недовольством зале он не нашел. Не дождался заказчик, и, наивно полагая, что в следующий раз повезет больше, заказал желанную порцию заново...

А теперь давайте вспомним, а ради чего весь этот кипишь? А все ради одного: только для удобства нашего шеф-повара. Поэтому наш шеф-повар удовлетворенно отмечает полное соответствие процесса технологическим картам и срочно готовит управляющему служебную записку примерно такого содержания: "Во избежание повторения сбоев, произошедших тогда-то и тогда-то, прошу срочно разместить зону временного хранения в более доступном месте, увеличив количество стеллажей и мест доступа к этим стеллажам. Кроме этого следует увеличить количество работников кухни, расширить ее рабочее пространство, а еще ..." и т.д. и т.п. Переместив направленный в него кол в сторону технической службы, наш шеф-повар удовлетворенно вздыхает и приступает к раздаче новых команд, и конечно же главная и самая любимая из них - ПОМЕСТИТЬ во временное хранилище. Потому, что он так привык. Потому, что он просто так хочет. Потому, что окружающие, включая и владельцев бизнеса, оплачивающих это его желание, и многострадальных пользователей, сидящих перед зависшими экранами и печально наблюдающих колесико курсора ожидания, не разбираются в магическом мире ЕГО КУХНИ и не знают, что все заказанные ими блюда можно приготовить существенно быстрее и с гораздо меньшими затратами просто исключив из процессов его любимую ЗОНУ ВРЕМЕННОГО ХРАНЕНИЯ. А самое печальное, что и сам шеф-повар этого не знает и не понимает - ну нет этого в авторитетных книгах, на которых он становился сертифицированным МАСТЕРОМ 1С.

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

P.S. Несколько лет назад я прочитал замечательный бестселлер Алана Купера "Психбольница в руках пациентов". Эта книга полностью перевернула мое отношение к программной разработке и к сфере информационных технологий в целом. И хотя с того времени минуло много лет, данная статья написана, в немалой степени, под влиянием этой книги. Кто не читал, прочтите - очень советую.

-2

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. user774630 13.03.19 20:22 Сейчас в теме
Вы на техническом ресурсе решили объяснить, почему не ЛЮБИТЕ временные таблицы на примере кухни и повара?
IgorS; gubanoff; Ганс; Igor_K_; alest; Vladimir Litvinenko; TMV; bulpi; akim2040; Casey1984; semagin@gmail.com; kadild; +12 Ответить
96. dmitrydemenew 32 18.03.19 13:51 Сейчас в теме
(1)Согласен, здесь это невозможно объяснить на любом примере. Слишком велик неформат информации и нежелание аудитории ее воспринимать. Даже удивляюсь, с чего столько внимания. Наверное, слишком высока ценность, раз ее так рьяно все бросились защищать. Ну а я лишний раз убедился, что мое умение из неработающего делать работающее еще долго будет в цене.:)
97. genayo 18.03.19 13:55 Сейчас в теме
(96) Столько внимания потому, что на техническом (пока) ресурсе пишете статью с весьма смелыми заявлениями, не приводя при этом никаких технических обоснований.
98. dmitrydemenew 32 18.03.19 14:05 Сейчас в теме
(97) Обоснование в (86)
Более полное описание технической стороны проблемы, к сожалению не пропущено модератором. Т.к. объяснений почему нет, то я, предполагаю, из-за несоответствия информации формату ресурса.
99. genayo 18.03.19 14:29 Сейчас в теме
(98) Вы, конечно, извините - но объяснение "из-за временных таблиц у меня 1С висит" - это несерьёзно.
101. dmitrydemenew 32 18.03.19 15:02 Сейчас в теме
(99)К сожалению, это факт. Факт, который можно "потрогать", в существовании которого может убедится любой желающий собственными глазами. Или Вас абсолютно не смущает, что количество информации, проходящей через темповую базу за единицу времени почти в 100 раз превышает количество данных полученных и записанных в реальную базу 1С? Количество данных записи в tempdb - почти в 200 раз! Это ЗАПИСЬ НА ДИСК - самая ресурсозатратная операция с данными! Я конечно уже понял, что стучусь головой в стену, но крупица надежды, что хоть кто-то об этом задумается еще жива. А представленная картинка с диким количеством записи и чтения времяков - это не самая печальная картина из тех, что мне приходится наблюдать.
102. genayo 18.03.19 15:25 Сейчас в теме
(101) А в наблюдаемой мной системе 1С не "виснет", и значит никакой проблемы с временными таблицами нет?
Исследование, чтобы быть убедительным, должно содержать описание исходного состояния, проблемы, описание вариантов решения проблемы, и сравнение исходного и полученного состояния. Иначе всё это похоже на обычное нытьё. Вы же не приводите никаких доказательств, что если вместо временных таблиц использовать подзапросы - тормозов не будет. Я точно так-же могу сказать, что использование подзапросов приведёт к тормозам 1С из-за нехватки памяти сервера. Вы, может быть, и правы, только вот свою правоту доказать фактами не хотите/не можете.
104. Magellan32 18.03.19 16:04 Сейчас в теме
(102) Автор и не утверждает, что ВТ не имеют право на жизнь.

Наверно, одинаково неправы - и те, кто "всегда и везде только за ВТ", и те, у кого "только подзапросы, а ВТ - зло".

Непонятно, какие нужны от автора доказательства?

Точно так же можно сказать - приведите доказательства обратного свойства.
Докажите, обоснуйте, что "применение ВТ всегда и везде", - никогда не приводят к ощутимым тормозам в работе.
105. genayo 18.03.19 16:11 Сейчас в теме
(104) Вот вам статья автора была полезной? Вы из неё узнали что-нибудь, кроме того, что у любого инструмента есть положительные и отрицательные стороны?
106. Magellan32 18.03.19 16:38 Сейчас в теме
(105) Смотря что принять за критерий "полезности".

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

Однако автор правильно заметил - наблюдается "перекос" разработчиков 1С в повальном применении ВТ - не всегда обоснованный.
И далеко не факт ещё, что это всегда приводит к наглядности кода.

"Полезность" для меня в этом - я тоже пришел в свое время для себя к такому выводу - ВТ не панацея. Иногда и зло - если его много.
Лично я имею ввиду типовые решения 1С 8.3 БП30 и ЗУП31.
107. dmitrydemenew 32 18.03.19 16:45 Сейчас в теме
(102)Если Ваша 1С работает стабильно, мне непонятен Ваш интерес к теме оптимизации ее работы.
Я изначально определил проблему так: нестабильная работа типовых конфигураций 1С в крупных информационных системах из-за перенасыщения кода командами "Поместить".
Основные факторы, определяющие мое отношение к этой проблеме таковы:
1. Реально наблюдаемое огромное количество трудоемких физических операций с жестким диском, в разы превышающих число операций с БД хранения и вызванных обработкой временных данных.
2. В немалой степени причина возникновения зтих трудоемких операций - и это подтвердило большинство участников обсуждения - связана с использованием временных таблиц с целью более удобной работы с программным кодом.
3. В результате выполнения этих трудоемких операций, что вполне логично при их критическом увеличении, "зависает" 1С и пользователи программы ощущают существенное неудобство.
4. Я, как специалист, отвечающий за отсутствие этого неудобства, недоволен источником этих неудобств, о чем и сообщил в этой публикации с целью хоть немного притормозить технически необоснованное использование этого инструмента.
2. haereticus 13.03.19 20:32 Сейчас в теме
Такое бы не в хайлоуд, а прямиком в графоманство
Igor_K_; alest; user774630; +3 Ответить
3. DNN13 13.03.19 21:57 Сейчас в теме
И что делать если временная таблица всеже нужна?
4. dmitrydemenew 32 13.03.19 23:19 Сейчас в теме
(3)В случае, когда использование временной таблицы - лучшее решение, конечно необходимо ее использовать. Я не считаю допустимым, если ВТ используются, к примеру, только лишь для лучшей читаемости кода и т. п.
85. wolfsoft 2420 18.03.19 10:31 Сейчас в теме
Правильно, и визуальный редактор в топку, кодом надо форму создавать со всеми элементами. Даёшь переменные из двух букв и код столбиком! Да и вообще на ассемблере писать надо - код компактный, быстрый, технических ресурсов требует меньше :) А пока пишешь код, глядишь, уже "ишак помер" (с) ))
5. kadild 14.03.19 01:24 Сейчас в теме
Когда гуманитраий на голодный желудок фантазирует про поваров понятия не имея про техническую сторону)) Автору по душе склад продуктов где сидят повара и отбиваются от голодных зомби?) Идеальная скоростная система кухни - Макдак и там абсолютная противоположность ваших размышлений.
Временные таблицы улучшают читаемость кода, отладку и поддержку, а это самое дорогое. Что касается производительности, то благодаря временными таблицам SQL базе легче предсказать план запроса и препроцессору легче оптимизировать. Те кто строят лесенки из кучи соединений - страшные извращенцы.
Поймите наконец, текст вашего запроса и код плана запроса с большой вероятностью не будет совпадать после оптимизации перед выполнением запроса. Код в 1с в отладке и скомпелированный код запущенный в режиме предприятия без отладки будут отличаться и последний оптимизированный препроцессором всегда выполняется быстрее.
К чему это я, пишите понятный для людей код, а не для машины.
itmind; Igor_K_; saroman; Irwin; alest; bulpi; HAMMER_59; acanta; semagin@gmail.com; mysm; +10 1 Ответить
8. dmitrydemenew 32 14.03.19 04:57 Сейчас в теме
(5)я не голодный гуманитарий, я программист с пятнадцатилетним стажем. Спасибо за Ваш ответ, потому, что моя публикация именно об этом, об нашем отношении программе. Для кого существует программа, для программиста, пишущего ее код или для пользователя использующего программы? Что важнее, удобство программиста, или удобство пользователя?
9. acanta 47 14.03.19 05:12 Сейчас в теме
(8)Вы когда нибудь рубили дрова топором? Если ручка топора будет неудобной это просто опасно для жизни. А кто будет создавать себе тепло и насколько оно будет теплым вас конечно же волнует, но только пока вы не отрубите вашим же инструментом что нибудь нужное самому себе.
Olenevod; saroman; bulpi; kadild; Wdivine; +5 1 Ответить
12. dmitrydemenew 32 14.03.19 05:49 Сейчас в теме
(9)топорище то у нас удобное, красивое, художественной резьбой украшенное. Вот только замерзающие дожидаются дров далеко не всегда
13. acanta 47 14.03.19 05:52 Сейчас в теме
(12) Вы считаете художественная резьба на топорище совместима с удобством?
Или вас беспокоит выполнимость обещания замерзающим?
Если бы мужчина имел возможность жениться на всех, кому он когда либо что-то пообещал, то его можно было назвать хозяином.
Или вы имеете ввиду модель поведения мужчины, который верит что у него есть такая возможность, но нет желания содержать такое количество жен и детей?
10. akahepad 7 14.03.19 05:29 Сейчас в теме
(8)
(5)я не голодный гуманитарий, я программист с пятнадцатилетним стажем. Спасибо за Ваш ответ, потому, что моя публикация именно об этом, об нашем отношении программе. Для кого существует программа, для программиста, пишущего ее код или для пользователя использующего программы? Что важнее, удобство программиста, или удобство пользователя?

Что дешевле в долгосрочной перспективе для предприятия, купить в 2 раза более мощный сервер или нанять в 2 раза больше программистов? Что предпочтительнее для руководителя предприятия, шустрая система которую адекватно может поддерживать только её автор , или более медленная, на поддержку которой можно всегда без проблем найти специалистов? Не путайте свой перфекционизм программиста и удобство пользователя. Во всём должна быть мера.
Ганс; wolfsoft; dabu-dabu; saroman; Aggressorak; bulpi; kadild; Wdivine; +8 Ответить
14. dmitrydemenew 32 14.03.19 06:53 Сейчас в теме
(10)
Я, как руководитель ИТ-подразделений со стажем более 8 лет, знаю о том, что дешевле для предприятия не понаслышке. И не вижу никаких проблем в поиске специалистов 1С с легкостью читающих и пишущих запросы без использования временных таблиц.
91. Timur.V 45 18.03.19 12:40 Сейчас в теме
(14)
Если у вас такой большой опыт, тогда вы должны знать о существовании HDD и оперативной памяти.
При написании запросов, вы можете делать упор на использование одного или другого т.е. чего в избытке на сервере ms sql.
Поэтому стиль написания запросов может быть продиктован и этим.
92. acanta 47 18.03.19 12:44 Сейчас в теме
(91) Вы хотите сказать, что при размещении tempDB на диске или на ram диске в оперативной памяти нужны разные конфигурации 1с?
Исключительно по стилю оптимизации?
93. Timur.V 45 18.03.19 12:50 Сейчас в теме
(92)
1) При использовании временных таблиц - используется жесткий диск, его ресурсы.
2) Про НЕ использовании временных таблиц - используется оперативная память сервера.

В идеале - нужно писать всегда по варианту 2. По скорости - быстрее будет.

Если оперативной памяти мало, можно - по первом варианту писать запросы.
Да, будет страдать скорость. Зато, мы используем все имеющиеся ресурсы сервера.
94. dmitrydemenew 32 18.03.19 13:16 Сейчас в теме
(93)Вопрос даже не в скорости, хотя я считаю скорость важным показателем качества работы программы. Вопрос в том, что 1С зависает "наглухо", т.е. регулярно и по-долгу нее работают все сессии 1С. Не работают ни медленно ни быстро. И связано это исключительно с использованием временных таблиц. Чем бы это использование ни аргументировалось, мне, как специалисту, ответственному за бесперебойную работу программы, это не может нравится. Я уже понял, что это та еще борьба с "ветряными мельницами". Но вопрос все-же поднят, и, надеюсь, что его обсуждение поможет кому-то разобраться с собственными проблемами зависания 1С и решить их.
65. buganov 54 15.03.19 13:15 Сейчас в теме
(10) что дороже для предприятия, программист, который пишет оптимизированные запросы или постоянная покупка мощностей? Посчитайте на примере хотя бы сотни человеко-часов в сутки, сколько стоит ожидание сотрудников и прикиньте, а стоит ли брать на работу недоучку
17. HAMMER_59 77 14.03.19 07:36 Сейчас в теме
(8) Не плохо бы для начала измерить насколько же увеличиться быстродействие.
Я сейчас перевожу холдинг со старых конфигураций без управляемых форм, в т.ч. с 7-ки, на новые, пользователи бесконечно жалуются, что "в этих новых конфигурациях всё тормозит".
Давайте по-другому поставим вопрос, что удобнее пользователю, мнимая скорость работы (не факт, что он заметит прирост скорости, не факт даже что будет прирост), или количество ошибок в программе?
26. user614822 25 14.03.19 10:02 Сейчас в теме
(8) Вы думаете пользователь знает о существовании временных таблиц?
А вот программисту далеко не все равно - что вы там наваяли - аккуратные легко читаемые и структурированные временные таблицы или суперзапутаную супервложенную цепочку вложений...
Вы думаете , что создали нетленку и ваш код никто и никогда не будет дописывать и изменять - глубоко ошибаетесь!
И пользователям тоже не все равно - неделю будут делать простейшие дописки, разгребая вам только понятный код, или за день доделают то что вы там насоздавали...
27. sergathome 14.03.19 10:22 Сейчас в теме
(26)
суперзапутаную супервложенную цепочку вложений

оно таким становится ИСКЛЮЧИТЕЛЬНО потому, что вендор не предоставил средств работы с подобными запросами, что тупо печально, как и многое другое в платформе
29. HAMMER_59 77 14.03.19 10:32 Сейчас в теме
(27)
оно таким становится ИСКЛЮЧИТЕЛЬНО потому, что вендор не предоставил средств работы с подобными запросами, что тупо печально, как и многое другое в платформе


Занятно. Можно поподробнее про инструменты работы с запросами, офигенно удобными, ато я как не спрошу вэб-разработчиков, как они запросы пишут, так они тупо текстом пишут. Многие 1С-ники даже не оценят насколько это "здорово", привыкли просто через точечку писать, а дальше 1С сама соединит таблицы.
31. sergathome 14.03.19 11:29 Сейчас в теме
(29) Поподробнее - в гугл. Точечка, кстати, зло такого же уровня, как и ВТ. Да, иногда удобно. Но не более.
33. AntonSm 22 14.03.19 11:51 Сейчас в теме
(31) напишите, пожалуйста, с какими ключевыми словами идти в гугл.
Узнать о существующих удобных инструментах для работы всегда интересно и полезно.
37. sergathome 14.03.19 13:41 Сейчас в теме
(33) например Visual Studio + PL-SQL. Сюрпрайз, понятнож...
38. AntonSm 22 14.03.19 14:14 Сейчас в теме
39. sergathome 14.03.19 14:16 Сейчас в теме
(38) я имел ввиду любую приличную среду разработки под SQL.
40. AntonSm 22 14.03.19 14:18 Сейчас в теме
35. HAMMER_59 77 14.03.19 12:42 Сейчас в теме
(31) Забавно, сначала написали, ах он этот вендор 1С не предоставил удобных инструментов разработки, а когда задали очевидный вопрос "Что это за волшебные средства разработки?", сразу отмаз "да погуглите". Понятно все с вами - демагог.
36. sergathome 14.03.19 13:40 Сейчас в теме
66. buganov 54 15.03.19 13:16 Сейчас в теме
(31)чем точка в запросе плоха?
68. sergathome 15.03.19 13:18 Сейчас в теме
(66) она развращает слабых духом
rudnitskij; +1 Ответить
70. buganov 54 15.03.19 13:24 Сейчас в теме
(68) а в чем же разница тогда между
Выбрать Т.Ссылка, Т.Склад, Т.Склад.ВидЦен Из Документ... Как Т
От
Выбрать Т.Ссылка, Т.Склад, Т1.ВидЦен Из Документ... Как Т Левое соединение Справочник.ВидыЦен По Документ.ВидЦен = Справочник.Ссылка
? )
На стороне СУБД одинаково будет)
72. sergathome 15.03.19 13:28 Сейчас в теме
(70) не всегда, коллега. слабый духом может так доработать Справочник.ВидЦен, что (кстати, ваш запрос неправильно соединяется, надо бы соединять по Склад или что вы там имели ввиду, но не суть), что в результирующем запросе к БД окажется таблиц -дцать ;))

ЗЫ и всё бы оно бы и ничего, если бы размер этих таблиц не имел тенденции меняться....
80. buganov 54 16.03.19 11:37 Сейчас в теме
(72)да, имелась ввиду таблица склад, конечно же, из нее же через точку забираем вид цены.
И не важно, сколько весит таблица, на SQL такой запрос будет всегда одинаков.
82. sergathome 16.03.19 14:30 Сейчас в теме
(80) Коллега, не будет, увы, и не будет, особенно увы, его конечный план запроса в конечной БД, коллега...
84. buganov 54 18.03.19 05:05 Сейчас в теме
(82)что, правда, что ли? И в чем же отличия в запросах? Еще и плюсанул кто то... Вы мне точно коллега?

ВЫБРАТЬ
	ЧекККМ.Ссылка,
	ЧекККМ.Валюта,
	ЧекККМ.Валюта.Наименование
ИЗ
	Документ.ЧекККМ КАК ЧекККМ
		
ГДЕ
	ЧекККМ.Дата > &Дата

SQL

SEL ECT
T1._IDRRef,
T1._Fld3669RRef,
T2._Description
FR OM _Document193 T1 WITH(NOLOCK)
LEFT OUTER JOIN _Reference25 T2 WITH(NOLOCK)
ON T1._Fld3669RRef = T2._IDRRef
WHERE (T1._Date_Time > @P1)


ВЫБРАТЬ
	ЧекККМ.Ссылка,
	ЧекККМ.Валюта,
	Валюты.Наименование
ИЗ
	Документ.ЧекККМ КАК ЧекККМ
		ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Валюты КАК Валюты
		ПО ЧекККМ.Валюта = Валюты.Ссылка
ГДЕ
	ЧекККМ.Дата > &Дата
Показать

SQL

SELECT
T1._IDRRef,
T1._Fld3669RRef,
T2._Description
FR OM _Document193 T1 WITH(NOLOCK)
LEFT OUTER JOIN _Reference25 T2 WITH(NOLOCK)
ON T1._Fld3669RRef = T2._IDRRef
WH ERE (T1._Date_Time > @P1)
100. sergathome 18.03.19 14:30 Сейчас в теме
(84) какой ты душный, коллега. на, почитай
https://infostart.ru/public/204054/

6. Разыменование полей.

Обращение к полям через точку называется операцией разыменования ссылочного поля. Например Оплата.Организация.АдминистративнаяЕдиница. В этом случае в ссылочном поле "Организация" документа "Оплата", ссылается на другую таблицу "Организации", в которой будет получено значение реквизита "АдминистративнаяЕдиница". Важно понимать, что при обращении к полям через точку платформа неявно создает подзапрос и соединяет эти таблицы.

Запрос:

ВЫБРАТЬ
Оплата.Ссылка,
Оплата.Организация,
Оплата.Организация.АдминистративнаяЕдиница
ИЗ
Документ.Оплата КАК Оплата
Можно представить в виде:

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

При разыменовании ссылочных полей составного типа платформа пытается создать неявные соединения со всеми таблицами, которые входят в тип этого поля. В этом случае запрос будет неоптимален.Если четко известно, какого типа поле, необходимо ограничивать такие поля по типу конструкцией ВЫРАЗИТЬ().

Например имеется регистр накопления "Нераспределенные оплаты", где регистратором могут выступать несколько документов. В этом случае неверно получать значения реквизитов регистратора таким образом:

ВЫБРАТЬ
НераспределенныеОплаты.Регистратор.Дата,
.....
ИЗ
РегистрНакопления.НераспределеныеОплаты КАК НераспределенныеОплаты
следует ограничить тип составного поля регистратор:

ВЫБРАТЬ
ВЫРАЗИТЬ(НераспределенныеОплаты.Регистратор КАК Документ.Оплата).Дата,
.....
ИЗ
РегистрНакопления.НераспределеныеОплаты КАК НераспределенныеОплаты
Показать
109. buganov 54 18.03.19 17:55 Сейчас в теме
(100) послушай, человек, который норовит в коллеги. Я тебе скинул запросы на стороне 1С и на стороне SQL, а ты мне статейками бросаешь в глаза. К тому же, я тебе то же самое написал, только чуть ниже уровнем(уровень СУБД).Точка в запросе ничем не плоха, если поле не составного типа, а если составного, то нужно отсечь его через выразить.
Для обращение через точку в коде(быдлокод) есть отличный БСПшный метод Общегоназначения.ЗначениеРеквизитаОбъекта(Объект, ИмяПоля);

И я повторю свой вопрос. Чем плоха точка в запросе?
49. dmitrydemenew 32 14.03.19 19:58 Сейчас в теме
(26)нет, наши пользователи не знают о временных таблицах, зато большинство из них очень хорошо знает, что такое зависание 1С
56. user614822 25 15.03.19 09:06 Сейчас в теме
(49) Вы занимаетесь безаргументированной демагогией!
Я с таким же успехом могу утверждать, что конечно же пользователи очень недовольны зависанием 1С из-за неоптимальных запросов с кучей вложений...
А временные таблицы - оптимизаируют эти запросы.

На самом же деле вопрос области применения временных таблиц и вложений ДАВНО решен и не в пользу одного или второго - у каждого есть свои границы применения, если вы не знаете этого - рекомендую углубиться и изучить...
И ясно что если применять временные таблицы там , где вложение более эффективно - это ошибка программиста, но абсолютно верно и высказывание, что если вместо временной таблицы использовать вложенный запрос там , где более эффективна таблица , это приведет к тормозам и возможным зависаниям...

Вы же не будете стрелять из пушки по воробьям , а из дробовика по танкам? Хотя сейчас примерно такое и предлагаете - перевооружить всех одним видом оружия!
wolfsoft; alo; +2 Ответить
18. milanse 32 14.03.19 07:38 Сейчас в теме
(5) А есть ли где-то подтверждение , того, что по временным таблицам строится более оптимальный план запроса? Недавно только читал, что в постгри точно не оптимальный строится.
Есть ли вообще смысл что-то помещать во временную таблицу, если данные из нее используются потом только один раз ?
25. sergathome 14.03.19 09:39 Сейчас в теме
(18) я пришёл к выводу, что обычно смысла нет. бывают, очень редко, странные выкидыши оптимизатора, когда просто приходится делать ВТ, но это, скорее, исключение.
34. Bеgemoth 14.03.19 12:32 Сейчас в теме
(18) "Если запрос содержит соединения с подзапросами, то это может привести к следующим негативным последствиям:
-Крайне медленное выполнение запроса при слабой загрузке серверного оборудования. Замедление запроса может быть очень значительным (до нескольких порядков).
-Нестабильная работа запроса. При некоторых условиях запрос может работать достаточно быстро, при других - очень медленно.
-Значительная разница по времени выполнения запроса на разных СУБД.
-Повышенная чувствительность запроса к актуальности и полноте статистик. Сразу после полного обновления статистик запрос может работать быстро, но через некоторое время опять замедлиться."

https://its.1c.ru/db/metod8dev#content:5842:hdoc
Ганс; +1 Ответить
67. buganov 54 15.03.19 13:18 Сейчас в теме
(34)подзапрос в соединении совсем другое, ну путайте теплое с мягкий. ТС говорит про вложенные запросы
76. ADirks 180 15.03.19 14:20 Сейчас в теме
Кстати, всегда удивляло, откуда взялось утверждение, приведённое в (34) ?
Каким боком вложенность запросов влияет на использование статистик оптимизатором? Для парсера запросов эта ваша вложенность вообще не важна, в итоге весь запрос развернётся в "линейную" структуру. А исполняющий механизм сервера точно так же выполняет table scan/partial index scan/index seek в зависимости от имеющихся в наличии статистик.
Вот непопадание в индексы - это действительно зло.
48. dmitrydemenew 32 14.03.19 19:29 Сейчас в теме
(5)Вот только Ваш код выполняют не люди, а машины. А вот результатом выполнения этого кода пользуются как раз люди.
64. buganov 54 15.03.19 13:13 Сейчас в теме
(5) самое дорогое это ресурсы сервера и время ожидания кучи сотрудников, ожидающих голодным взглядом своих данных.
Улучшаю читаемость - несомненно, поддерживать легче, да, возможно, но самое ли это дорогое?
Представьте себе, что Вам нужно выбрать гигантское количество данных и положить во временную таблицу. Время на выборку, время на то, чтобы положить в темпдб, а еще и вытолкнуть при этом кэш. С чего Вы взяли, что SQL при этом легче оптимизировать? Он знать не знает про то, что в ВТ понапихал программист. Он так же по новой делает запрос к новой таблице, пусть индексированной. Зачем все это?
К чему это я, пишите понятный для машины код, а люди пусть быстрее получают свои данные, не не ждут из-за того, что "программист" поленился сделать оптимальную выборку, понятную машине.
И да, приведу пример из недавнего. Отчет делал выборки и складировал данные по временным таблицам. Одна из них пыталась положить данных на 300Гб и делала это столько, что пользователи просто выкручивались, шли другими путями, но игнорили отчет. Стоимость выполнения этого куска кода был порядка 50 тысяч баллов! Причем самое интересное, что искомые ВТ использовались один раз в результирующем пакете. Так вот, при переписывании выборки с ВТ на частичную замену подзапросами стоимость всего запроса отчета стала 4 тысячи. Почувствуйте разницу
90. Timur.V 45 18.03.19 12:36 Сейчас в теме
(5)
Что касается производительности, то благодаря временными таблицам SQL базе легче предсказать план запроса и препроцессору легче оптимизировать.

ms sql ищет в куче без интексов
6. script 199 14.03.19 02:27 Сейчас в теме
Что-то я ничего из статьи не понял, кроме личного мнения автора.
81. buganov 54 16.03.19 11:39 Сейчас в теме
7. PowerBoy 2885 14.03.19 04:53 Сейчас в теме
Аналогия не катит, на кухне для каждого клиента своя кладовка.
11. Y_U_S 17 14.03.19 05:33 Сейчас в теме
Проникся мыслью... Буду стараться принести всё из кладовой сразу, чтобы потом готовить, не отходя от стеллажей.

Действительно, так привык пользоваться ВТ, что уже и краёв не вижу. Недавно запихнул всё в ВТ (потенциально 2-3 строки), чтобы потом свернуть её на финальном запросе. Чего бы сразу всё не свернуть было?

С дипломницей недавно писали запрос: 10 временных таблиц для простеньких данных! Это можно, конечно оправдать: нужен блеск понимания в глазах студента. Но и про оптимизацию надо не забывать.
dmitrydemenew; +1 Ответить
15. HAMMER_59 77 14.03.19 06:55 Сейчас в теме
Забавное начало:
Начну с того, что в механизмах работы любых программ нет эзотерики и особой магии - все основано исключительно на элементарных законах физики и математики, как и весь окружающий нас мир.


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

Про остальной текст статьи уже достаточно комментариев, мягко говоря странно, на инфостарте уходить в какую-то непонятную абстракцию, можно подумать здесь всем ресторан куда ближе чем 1С.
Ганс; EVKash; +2 Ответить
16. dmitrydemenew 32 14.03.19 07:17 Сейчас в теме
Из сочинений Михаила Жванецкого:
"Смешно подходить к театру с точки зрения зрителя. На спектакли не ходят – от скуки челюсть выскакивает. А то, что режиссер непрерывно ищет и ставит, ставит и ищет? Театр первым отрапортовал о подготовке к зиме, ни одного актера, не занятого в спектакле. При чем тут пустой зал? Тогда получается, что театр – для зрителя, поезд – для пассажиров, а завод – для покупателя?! Такой огромный завод – для покупателя? Нет! Это для всеобщей занятости.
Пароход – для команды, паровоз – для машиниста, столовая – для поваров, театр – для актеров, магазин – для продавцов, литература – для писателей! Нет и не может быть выхода из этих предприятий – настолько увлекательный процесс внутри. Смешно ждать снаружи чего-либо интересного. Схватил у самого передового коллектива пылесос – он не работает, потому что не он главный. При чем тут борщ, когда такие дела на кухне?!"
http://odesskiy.com/zhvanetskiy-tom-3/parovoz-dlja-mashinista.html

ПАРОВОЗ - ДЛЯ МАШИНИСТА, 1С - ДЛЯ ПРОГРАММИСТА!
19. HAMMER_59 77 14.03.19 08:18 Сейчас в теме
(0) Мозг готов хоть-чем заниматься лишь бы не работой :) , пример в абстракции кухни:
Пришли вы в ресторан и что для вас важнее:
1. Чтобы вам за 5 минут все принесли.
2. Или Вам важнее, чтобы всех ингредиентов было столько сколько нужно (например, не пересолили), чтобы не пригорело и т.д. и т.п.

Естественно хочется все и сразу, но тут как всегда: быстро, дешево, качественно выбирай любые два :)
Дорого редко кто выбирает, типа а зачем нам эта БП:3.0 давай лучше наймем штат программистов и под себя напишем с нуля, и вобще не на 1С, а на ассемблере.
21. dmitrydemenew 32 14.03.19 08:40 Сейчас в теме
(19)Если я пришел в ресторан, то для меня важно получить удовольствие от своевременно принесенной и очень вкусной еды, сопровождаемой великолепным сервисом. Именно за это я готов платить и буду возвращаться в этот ресторан снова и снова. Если же удовольствие не получено, то это не ресторан а посредственная столовая, потому, что в моей картине мира ресторан существует исключительно для того, чтобы делать в первую очередь счастливыми посетителей, а не служащих этого ресторана.
28. HAMMER_59 77 14.03.19 10:25 Сейчас в теме
(21)
важно получить удовольствие от своевременно принесенной

Уже появилось слово своевременно, а это уже совсем другой критерий, т.е. Вам не надо как можно быстрее, вам надо именно качественно, а не максимально быстро. Уверен что и за максимально качественно вы тоже не готовы переплачивать (на порядок переплачивать).
20. 3vs 14.03.19 08:38 Сейчас в теме
А не пора уже 1С добавить в поддержку какую-нибудь СУБД в оперативной памяти?
Смотришь и работать шустрее будет...
22. sergathome 14.03.19 09:20 Сейчас в теме
(20) ага, добавили уж sqlite однажды в одно место... ;))
46. o4karek 14.03.19 17:40 Сейчас в теме
(20) Так добавили в 14-й версии. Именно in-memory DB. Там только требования по памяти немного большие
52. 3vs 15.03.19 05:48 Сейчас в теме
(46)А это работает не только в КОРП версии?
58. o4karek 15.03.19 09:20 Сейчас в теме
(52) и что? Работает же
Спич-то был: "А не пора уже 1С добавить в поддержку какую-нибудь СУБД в оперативной памяти? "
Во они и добавили.
23. sergathome 14.03.19 09:28 Сейчас в теме
Автор упустил самый смешной выкидыш при использовании ВТ - это их индексирование. Регулярно натыкаясь на подобные шЫдевры как-то начинаешь уже задумываться - а может это я дурак ? Потратил как-то время, поставил тест - ВТ на полтора десятка тыщ записей и три чтения из неё по одному ключу... Чуда не произошло - индексирование занимает времени почти в 10 раз больше чем 3 выборки без него.

зы с автором, в целом, согласен - всё хорошо к месту и в меру. писателей типовых и прочих коучей частенько заносит.
24. user803967 14.03.19 09:38 Сейчас в теме
У автора накипело о некомпетентности программистов.
И он спроецировал это все на времянки.
Временные таблицы - это инструмент.
И всегда будут те кто использует инструмент слишком рьяно.
Из-за этого не стоит ненавидеть инструмент.
Olenevod; +1 Ответить
30. acanta 47 14.03.19 11:20 Сейчас в теме
(24) у Вт есть альтернатива-. вложеннные запросы.
Использовать тот или другой инструмент как правило решает гуру, который готовит новичков.
Если сразу показать кому либо короткую дорогу, а самому идти по длинной, ни для кого не секрет чем кончается эта сказка.
В противном случае мы тут рассуждаем об энерджайзерах, которые будут работать до 10 раз дольше.
43. dadel 3 14.03.19 16:51 Сейчас в теме
(30)А если на постгрис работаем и вложенные запросы? На не нагруженных базах работать будет конечно, а в определенный момент вдруг запрос вместо 1 минуты формироваться станет часов 5-8...
Вложенный запрос сам по себе не вреден, вредно соединение с вложенным запросом. То же самое левое соединение с виртуальными таблицами в постгрисе падает на несколько часов.
И это помимо отсутствия возможности использовать результат вложенного запроса в разных пакетах.
haereticus; +1 Ответить
44. haereticus 14.03.19 17:16 Сейчас в теме
(30) Вложенные запросы имеют непрогнозированное время выполнения, именно поэтому 1С сделала такую альтернативу, как временные таблицы. Так что писать сейчас вложенными запросами - совсем дурной тон
45. sergathome 14.03.19 17:25 Сейчас в теме
(44) хыхы. есть сайт такой - udaff.com, так там дурной тон - не ругаться матом...
и кто вам, землянам, сказал, что в случае временной таблицы сразу всё становится шоколадным ? а, всё тот же, кто просто не умеет готовить вложенных ;))
32. Bеgemoth 14.03.19 11:40 Сейчас в теме
(0) Это очень странно устроенная кухня, в которой работникам в час пик не хватает места, чтобы разминуться в зоне временного хранения, но в то же время хватает дверного проема, ведущего в кладовую, чтобы свободно протиснуться самим, да ещё и прихватить с собой все нужные повару продукты... Очень странно устроенная кухня... Очень...
41. triviumfan 10 14.03.19 16:27 Сейчас в теме
Слишком неинформативный пример из картинки темы. Итак понятно, что это рукоблуд, такое часто встречается в типовых, но тема то не про это, а про ВТ в целом...
110. dmitrydemenew 32 18.03.19 18:24 Сейчас в теме
(41)тема в первую очередь именно об этом
42. sutygin 32 14.03.19 16:45 Сейчас в теме
Я рассматриваю ВТ как инструмент.
Если я умею работать инструментом - то да, он мне нравится и я его люблю.
Если я не умею работать инструментом - то я выбираю другой, которым могу работать.
ВТ - удобный инструмент. Полезный..
Но соглашусь с автором - в типовых решениях да и не только давно уже стало назревать маниакальное применение, причем там где надо и не надо - бесит. Автор - я с тобой :)
dmitrydemenew; +1 Ответить
47. profiprog1c 179 14.03.19 19:01 Сейчас в теме
Я тоже не люблю использовать ВТ. Более того в типовых много не только ВТ, а и куча избыточного кода. Понятно, что все это делается для поднятия порога вхождения программистов. У меня есть знакомые, которые иногда любили поковырять 1С, старые обычные формы. В новые типовые на УФ они уже и не лезут.
dmitrydemenew; +1 Ответить
50. user1048024 14.03.19 22:18 Сейчас в теме
(47)
(48)
(49)
и тут оказывается что "решения нет" - у вас на 99 процентов (кода) решение от 1С, всё же вы что "тормозит" (причина зависания) не перепишите? Ну или при обновлении "слетит"
51. user1048024 14.03.19 22:32 Сейчас в теме
Я про то, что замечательно, что в этой теме вспомнили Жванецкого!!!, отмечу то, что автор опубликовал это в теме Highload? Уж вы то можете обойтись собственными "корпоративными" ресурсами чтобы не тормозило из-за 1С? или из-за не любви к временным таблицам?
53. Толямба 15.03.19 07:18 Сейчас в теме
Сегодня мы программируем без виртуальных таблиц,
А завтра мы смотрим порнуху без баб
54. asved.ru 36 15.03.19 08:38 Сейчас в теме
Автор пытается рассуждать о работе СУБД, не имея о ней ни малейшего представления. В свете фактических алгоритмов операций плана запроса приведенная аналогия неверна, т.к. затраты на временное дублирование данных обычно во много раз меньше затрат на их повторное сканирование.
Да, активное использование временных таблиц может повлечь рост pagelatch ожиданий, времени перекомпиляций или другие неочевидные последствия, это нужно понимать и уметь диагностировать. Но если судить по уровню автора, он вряд ли столкнется с внедрениями, на которых такие вещи имеют значение.
alo; Igor_K_; +2 Ответить
55. dmitrydemenew 32 15.03.19 09:02 Сейчас в теме
Я рассуждаю о работе СУБД, основываясь на экспертном знании внутреннего устройства баз данных 1С и на многолетнем успешном опыте оптимизации множества информационных систем. Я не отвергаю временные таблицы, как класс, это обычный рабочий инструмент обработки данных. Я отвергаю дикие и необоснованные с технической точки зрения способы использования этого инструмента, с которыми регулярно сталкиваюсь в программных продуктах 1С.
sergathome; +1 Ответить
57. genayo 15.03.19 09:08 Сейчас в теме
(55) Если у вас такой опыт - лучше бы написали техническую статью с рассмотрение плюсов и минусов временных таблиц с кейсами, а не это непойми что.
semagin@gmail.com; alo; МимохожийОднако; alest; sergathome; +5 Ответить
59. sergathome 15.03.19 10:02 Сейчас в теме
(57) Кстати да. Только врятли кто на это сподвигнется. Объёмчик-с, однако.
60. genayo 15.03.19 10:13 Сейчас в теме
(59) Всеобъемлюще да. Но статью, рассматривающую пару-тройку кейсов вполне реально написать, имея соответствующий опыт.
61. sergathome 15.03.19 10:19 Сейчас в теме
(60) вот - если честно - когда такой кейс возникает, то как-то абсолютно не до написания статей становится ;)
71. ImHunter 90 15.03.19 13:27 Сейчас в теме
(57) (59) Насчет кейсов - ну да, писать наверн объемно.
Для себя вывел такой подход.
Смотрю план запроса (из стандартной упр консоли запросов 1С). И обращаю внимание на колонку Вызовы/Факт. Чем там больше значение в какой-то строке, тем больше операций перебора строк. А значит, имеет смысл внимательнее рассмотреть выполняемую операцию и, может быть, вынести соответствующие данные во времянку с нужными индексами.
73. sergathome 15.03.19 13:35 Сейчас в теме
(71) Исследование много времени занимает. Когда для себя делаешь - то пофиг на научные объяснения - есть результат - значит есть. А тут придётся профайлерами обвешиваться, замеры делать и аргументированно доказывать... Ну нафик.
62. VmvLer 15.03.19 12:54 Сейчас в теме
я использую ВТ часто и густо по одной простой причине - запрос созданный год назад и сегодня будет прочитан также легко как и при его создании.

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

Если взять современные конфигурации ЗУП или УТ, то мы увидим, что львиная доля запросов построена на Вт, причем менеджер Вт "прыгает" по общим модулям и в результат запроса заезжают все новые вт. Когда эту логику просекаешь, то приходит понимание, что остальные способы получения результата из десятков таблиц были бы заведомо сложнее.

Я хочу сказать, что использование ВТ чаще продиктовано не мифическими вопросами производительности и догм 1С, а банальной простотой чтения и модификации запросов.

Остальное бла-бла-бла а ля "я не люблю" скорее упирается в лень, нежелание или неспособность в меняющемся мире получать новые знания и способности.

мож на пенсию, а?
wolfsoft; semagin@gmail.com; alo; Scop; Err0r; +5 1 Ответить
69. ADirks 180 15.03.19 13:22 Сейчас в теме
(62) ЗУП писали наркоманы, и приводить её в качестве примера для подражания я бы поостерёгся.
Разобраться в аде из десятков ВТ, которые непонятно откуда заехали, нисколько не проще.
dmitrydemenew; sergathome; +2 Ответить
74. sergathome 15.03.19 13:42 Сейчас в теме
(69) да уж, насчет "простоты чтения" кода ЗУПа я рыдалЪ. походу это товарсч из команды тех самых наркоманов :))
dmitrydemenew; +1 Ответить
79. Err0r 16.03.19 01:27 Сейчас в теме
(62) Полностью поддерживаю. Разбираться в наворотах ЗУПа, конечно, та еще головная боль, но ведь есть: Инструменты Разработчика (https://infostart.ru/public/15126/) с замечатильными функциями отладки запросов.
Считаю, что даже ЕСЛИ вдруг запрос с Временными таблицами будет чуть-чуть подольше выполняться, то все равно НАДО их использовать, для упрощения понимания кода.
По факту же практически всегда запросы с ВТ оптимизируются скюэль сервером лучше, чем хитрозавернутые. Про файловые базы - оптимизация запросов для них - это всегда лотарея. Не факт, что на другой версии платформы выбранный вариант будет оптимальным :(
86. dmitrydemenew 32 18.03.19 11:38 Сейчас в теме
(62)
"я использую ВТ часто и густо по одной простой причине - запрос созданный год назад и сегодня будет прочитан также легко как и при его создании"
-Возможно, это здорово, что Вы с легкостью читаете свои запросы, Я же, к сожалению, наблюдаю в своей инф. системе такую картину:

Причина негативного влияния использования временных таблиц не кроется в том, что они делают запросы более или менее оптимальными, проблема вообще не связана с алгоритмами программных модулей 1С. Проблема в том, что при каждом запросе данных из БД выполняются десятки, а порой сотни дополнительных операций записи/чтения в/из системной базы TEMPDB и в моменты более активной работы очередь чтения записи диска, на котором расположена темповая база вырастает настолько, что нормальная работа с ним становится невозможной. Результат – 1С «висит». В этом может убедиться любой специалист, открыв во время зависания 1С «Монитор ресурсов» на сервере SQL. На вкладке "Диск->Работа диска" с очень высокой степенью вероятности Вы обнаружите в топе на чтение-запись файл темповой базы и «заваленный» диск его хранения с длиной очереди в сотни раз превышающей нормальное значение. Это и есть та кутерьма вокруг «временных стеллажей», описанная в тексте публикации.
Оставьте свое сообщение