Особенности использования SQL запросов #321500

Недавно пришлось решать такую задачу. Из УПП в Бухгалтерию (серверный вариант 8.0) перебрасываются документы Инвентаризация товаров на складе. Затем нужно заполнить в этих документах учетные количества и суммы. Для этого в документе есть соответствующий обработчик по кнопке Заполнить. Правда, это не работало: программа думала несколько минут, но заполнения не происходила. В результате была исправлена ошибка в обработке запроса, и все заработало. Заполнение для документа около 10000 строк происходила минуты за 3. Каково же было мое удивление, когда мне предъявили документ с 11000 строк, где заполнение шло больше двух часов! Анализ показал, что «тормозит» запрос. Пришлось его детально проанализировать. Для получения остатков по складу нужно получить остатки по счету 41.01 в разрезу номенклатуры по данному складу. С количеством так и делается, а вот с суммой – сложнее. Дело в том, что здесь возможен вариант с ведением суммового учета по обоим субконто (как в V7),  а возможен – только по Номенклатуре. Тогда, чтобы получить сумму по некоторому товара данного склада, нужно сделать запрос по данному товару по всем складам (т.е. без указания фильтра по складу). Полученная сумма делится на количество, получается средняя цена товар по всей фирме. Эта цена умножается на количество по данному складу, и получается учетная сумма. Так и делается в запросе. Он имеет вид: Запрос1 по всем товарам документа и по складу документа ЛЕВОЕ СОЕДИНЕНИЕ Запрос2 по всем товарам документа (т.е. по всем складам) Связка идет по номенклатуре. Дальше при обработке выборки делаются вычисления, описанные выше. Сразу появился ряд вопросов к запросу.  1)  Здесь всегда делается два запроса, несмотря на то, что в     случае ведения суммового учета по складам второй запрос излишен     и даже вреден. 2)  Запрос2 делается по тому же фильтру номенклатуры, что и Запрос1 (по всем товарам данного документа). Хотя понятно, что нас интересуют только те товары в Запросе2, которые вошли в Запрос1 (разница может быть в разы и десятки раз). 3)  Левое соединение делается, когда правое множество является ПОДМНОЖЕСТВОМ левого, хотя здесь явно наоборот, поэтому NULL ситуации не могут случиться в принципе: ведь НА ВСЕХ складах товаров не еньше, ччем на любом из этих складов. Но ведь – работало… А в каком-то документе – перестало. Поэтому можно предположить, что дело не в алгоритмической небрежности, а в грубом сбое платформы при выполнении левого соединения. Для проверки я разъединил запросы и выполнил их последовательно с использованием для второго запроса массива номенклатуры, полученного их первого запроса. Что касается левого соединения, то это – очень простая вещь: читается первая таблица и для каждого товара находится запись во второй таблице. Причем в обработке выборки это левое соединение уже делается: читается табличная часть документа, находится запись в первой таблице, оттуда берется количество, находится запись во второй таблице, оттуда вычисляется цена и т.д. В конце концов, полученная программ стала работать те же три минуты (ну, на секунды быстрее), но без неожиданных сбоев. Выводы напрашиваются сами собой:  1)  Сила языка SQL заключается в том, что им можно НЕ     ПОЛЬЗОВАТЬСЯ, точнее, совсем им не пользоваться нельзя, но     использовать его нужно ТОЛЬКО для выборки данных. Никакой     дополнительной обработки (соединения и т.п.) делать не следует,     что бы нам ни говорили разработчики и методисты. Дело в том, что     алгоритмы этих соединений и т.п., примененные в V8, не     опубликованы, а даже если бы и были опубликованы, к своему коду     – доверия больше. 2)  Внушает надежду, что простой анализ и исправление явных и неявных сомнительных мест в запросах позволяет повысить быстродействие запроса на два порядка. Это говорит, что есть надежда существенно повысить прозводительность той же 8.0 (8.1,8.2 и т.п.) и в других похожих случаях.

Недавно пришлось решать такую задачу. Из УПП в Бухгалтерию (серверный вариант 8.0) перебрасываются документы Инвентаризация товаров на складе. Затем нужно заполнить в этих документах учетные количества и суммы. Для этого в документе есть соответствующий обработчик по кнопке Заполнить. Правда, это не работало: программа думала несколько минут, но заполнения не происходила. В результате была исправлена ошибка в обработке запроса, и все заработало. Заполнение для документа около 10000 строк происходила минуты за 3. Каково же было мое удивление, когда мне предъявили документ с 11000 строк, где заполнение шло больше двух часов! Анализ показал, что «тормозит» запрос. Пришлось его детально проанализировать. Для получения остатков по складу нужно получить остатки по счету 41.01 в разрезу номенклатуры по данному складу. С количеством так и делается, а вот с суммой – сложнее. Дело в том, что здесь возможен вариант с ведением суммового учета по обоим субконто (как в V7),  а возможен – только по Номенклатуре. Тогда, чтобы получить сумму по некоторому товара данного склада, нужно сделать запрос по данному товару по всем складам (т.е. без указания фильтра по складу). Полученная сумма делится на количество, получается средняя цена товар по всей фирме. Эта цена умножается на количество по данному складу, и получается учетная сумма. Так и делается в запросе. Он имеет вид: Запрос1 по всем товарам документа и по складу документа ЛЕВОЕ СОЕДИНЕНИЕ Запрос2 по всем товарам документа (т.е. по всем складам) Связка идет по номенклатуре. Дальше при обработке выборки делаются вычисления, описанные выше. Сразу появился ряд вопросов к запросу.  1)  Здесь всегда делается два запроса, несмотря на то, что в     случае ведения суммового учета по складам второй запрос излишен     и даже вреден. 2)  Запрос2 делается по тому же фильтру номенклатуры, что и Запрос1 (по всем товарам данного документа). Хотя понятно, что нас интересуют только те товары в Запросе2, которые вошли в Запрос1 (разница может быть в разы и десятки раз). 3)  Левое соединение делается, когда правое множество является ПОДМНОЖЕСТВОМ левого, хотя здесь явно наоборот, поэтому NULL ситуации не могут случиться в принципе: ведь НА ВСЕХ складах товаров не еньше, ччем на любом из этих складов. Но ведь – работало… А в каком-то документе – перестало. Поэтому можно предположить, что дело не в алгоритмической небрежности, а в грубом сбое платформы при выполнении левого соединения. Для проверки я разъединил запросы и выполнил их последовательно с использованием для второго запроса массива номенклатуры, полученного их первого запроса. Что касается левого соединения, то это – очень простая вещь: читается первая таблица и для каждого товара находится запись во второй таблице. Причем в обработке выборки это левое соединение уже делается: читается табличная часть документа, находится запись в первой таблице, оттуда берется количество, находится запись во второй таблице, оттуда вычисляется цена и т.д. В конце концов, полученная программ стала работать те же три минуты (ну, на секунды быстрее), но без неожиданных сбоев. Выводы напрашиваются сами собой:  1)  Сила языка SQL заключается в том, что им можно НЕ     ПОЛЬЗОВАТЬСЯ, точнее, совсем им не пользоваться нельзя, но     использовать его нужно ТОЛЬКО для выборки данных. Никакой     дополнительной обработки (соединения и т.п.) делать не следует,     что бы нам ни говорили разработчики и методисты. Дело в том, что     алгоритмы этих соединений и т.п., примененные в V8, не     опубликованы, а даже если бы и были опубликованы, к своему коду     – доверия больше. 2)  Внушает надежду, что простой анализ и исправление явных и неявных сомнительных мест в запросах позволяет повысить быстродействие запроса на два порядка. Это говорит, что есть надежда существенно повысить прозводительность той же 8.0 (8.1,8.2 и т.п.) и в других похожих случаях.

>> Сила языка SQL заключается в том, что им можно НЕ    ПОЛЬЗОВАТЬСЯ, точнее, совсем им не пользоваться нельзя, но    использовать его нужно ТОЛЬКО для выборки данных. Никакой    дополнительной обработки (соединения и т.п.) делать не следует,    что бы нам ни говорили разработчики и методисты. Повеселило...

трактат о безответной любви.

Спам?

Произошел сбой при загрузке сообщения. Повторная загрузка была излишней.

я бы сказал бред в острой форме...

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

у тебя словесный понос? или ты решил по Гения 1С косить?

Господа, у нас имеется кандидат на знвание "Почетный дятел-2008". Повеселил, повеселил... Скажи, ты когда-нибудь дело с базами данных имел, или просто решил "поделиться соображениями"? Для этого у нас есть Гений 1С - он настолько суров, что использует функции платформы, добавляя к ним префикс, а потом жалуется на "неправильное ТЗ".

Базы данных здесь не пр чем. Имеется тривиальная ошибка в платформе, из-за которой, в частности, распространено мнение о неэффективнсти V8. Устраняется незанчительной модификацией кода и трезвым скептицизмом.

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

Устраняется заменой кодера...

Он здесь как раз не включен. А если бы был включен, то исходный запрос все равно бы выполнился в том же виде - это одна из ошибок данного модуля. Там при выборке вторая часть запроса не обрабатывалась бы, но до этого нуждо ждать 2 часа. Если бы дело было в ошибке программиста, я вообще не стал бы писать ("кто без греха, пусть первый бросит камень"). Здесь - чистая ошибка платформы,Ю что и доказано в исходном сообщении. Это дает основание утверждать: не верьте рекомендациям по применению SQL ДЛЯ ОБРАБОТКИ, делайте ее сами.

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

SQL сервер здесь не при чем, пользователь про его существование вообще знать не обязан, он, что ли ЛЕВОЕ соединение гробит?

после перехода на 8.1 помниться... у расчетчика... за день не мог сформироваться документ "отражение зарплаты в регл.учете" ... на ночь поставил реиндексацию и обновление статистики средствами SQL... документ стал формироваться за 5 минут

пля... вот именно... нафига предприятию прог.. который не выполняет своих обязанностей?

Здесь общие рассуждения не проходят: платформа поймана за руку, однозначно. Любая гипотеза, как известно, опровергается всего лишь одним противоречащим примером.

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

В программировании это называется - системная зависимость. Должна быть исключена категорически.

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

Исправлять ошибки в программах помогает?

"Я глупостей не чтец, а пуще - образцовых" (Чацкий)

Я куею, сколько тут специалистов по "проблемам платформы". Ты сам-то читал, или (что более вероятно, т.к. в есть переносы, которые обвчно не ставятся) просто скопипастил?

Любой непредвзятый исследователь может по ссылкам в найти код, проанализировать и сделать собственные выводы о правильности или неправильности приведенных выводов (даже если не наткнется на катастрофическиое замедление из-за платформы). Кстати, примеров "глюков" платформы, трудно воспроизводимых, каждый практикующий программист может привести десятки... Дело здесь не в этом: суть в том, чтобы НЕ НАДЕЯТЬСЯ на платформу, "ручками" побольше делать - и воздастся...

Да что ж вы, сцуки, делаете, а? Я уже второй раз за неделю вынужден спросить: ты тупой? Ты сам-то для начала прочитай. "Глюки платформы" он, понимаешь, нашел... "трудно воспроизводимые" глюки, понимаешь... Бля, хрена ли ты занимаешься программированием? Ты умеешь отличить "глюк платформы" от "кривого запроса" вообще? Ты можешь назвать СУБД, которая бы могла отработать ситуацию, когда "нас интересуют только те товары в Запросе2, которые вошли в Запрос1"? Ты вообще программировать умеешь? Или только копипастить сатьи, в которых увидел много умных слов, которые сам не понимаешь?

Запрос составлен правильно, хотя и не совсем оптимально. И в большинстве случаев его применения все происходит правильно. Более того, и в этом документе с 11000 строк через два часа ожидания все заполняется. Просто увлечение ЛЕВЫМИ-ПРАВЫМИ соединениями без правильного понимания, какой код за ними стоит, приводит иногда к странным результатам...

Значит так. Для тупых: ты в состоянии отличить "глюк платформы" от "кривого запроса"? Расскажи-ка мне, птичка, где ты увидел "глюки платформы" и, что меня больше всего волнует, с какого полового органа ты возомнил себя программистом?

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

Если для 10999 строк все идет путем, а для 11000 - летит кувырком, то это назывется в технике: "потеря устойчивости". И просто "кривого запроса" здесь маловато. Тем более, что запрос сделан по всем рекомендациям и разработчиками фирмы 1С.

...(Defender aka LINN кипя от злости).... ЗЫ: Ребята погодите я за пивом сбегаю :))

Короче. Все с тобой понятно. На будущее запомни: выкладываешь текст - приводи ссылку.

Отдай словарь терминов хозяину - профессиональные термины из уст дилетанта звучат как издевательство. Для совсем тупых: почитай . В акую ветку - и без пива... Это вам минус!

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

Товарищ Сухов:"Абдуллу надо было через трубу брать...". Такие советы позворляют сводить простую проблему к более сложной...

Сдашься просто так? :)

Не говори сам с собой - ничего умного не услышишь. Я тебе все прощу, если скажешь, где такую траву берешь забористую. З.Ы. Ты, кстати, дай ссылку-то на , интересно посмотреть, что за долбоеб это написал.

Русские не сдаюцца! И пофиг, что я почти болгарин :)

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

+37 К тому же тебя опустили в :)))

Теорию управления ЧЕМ, позвольте спросить?

... жаль, ничему не научил. Это вызов?

Есть мнение, что нам лучше этого не знать, иначе нас найдет Чак Норрис.

это здесь лучшую траву дают? мне тоже отсыпьте

Как же я это пропустил-то... Пьяный совсем... Ташотыгаваришь... Я 7 лет "странствующим программистом" работал - ни разу не попадал в ситуацию, когда надо за час "найти ошибку и ее исправить".

Есть такая наука (раньше ТАР называлась). Еще Березовский по ней - член-корреспондент. Можно не знать, и книжек по программированию не читать, зато - читать другим нотации...

себе все забрал, не делится. :(

По теме мысли будут, или признаешь техническое поражение?

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

Меняй ник на "Колумб". В принципе, "Гений 1С-2" тоже свободен. Про скорость выполнения мне рассказывать не надо - на форуме есть куча спецов, которые меня обставят по всем параметрам. Заковыка в том, что ты в их число не входишь.

"Блажен, кто верует, легко ему на свете..."

Ты либо кавычки убери, либо пиши правильно. Я, знаешь ли, всесторонне развит. З.Ы. Где, блин, ссылка с текстом из ? Или это писал твой друг и ты не хочешь его выдавать?

ппц  "1)  Сила языка SQL заключается в том, что им можно НЕ    ПОЛЬЗОВАТЬСЯ, точнее, совсем им не пользоваться нельзя, но    использовать его нужно ТОЛЬКО для выборки данных. Никакой    дополнительной обработки (соединения и т.п.) делать не следует,    что бы нам ни говорили разработчики и методисты. Дело в том, что    алгоритмы этих соединений и т.п., примененные в V8, не    опубликованы, а даже если бы и были опубликованы, к своему коду    – доверия больше. " хм .. а я дурак всё запросы под 1000 строк пишу. думал работать быстрее будет а оно вон как оказывается - "к своему коду – доверия больше. ". и запросы мои оказывается не мой код уже. да и v8 из моих соединений хз что делает, а я почему то думал соединения. немного порадовало что оказывается в 8ки нужно запрос использовать "ТОЛЬКО" для выборки данных. видимо изза дремучести я как то пропустил в языке запрос 8ки много полезных команд - delete update insert  и пользовался только select. что и спасло меня от страшных ошибок. ну а что сила sql в том что им можно не пользоваться для меня прям как озарение. еще б автор сего опуса объяснил бы мне для чего нужна база данных крутящяяся на скуле если запросы к ней не делать, чето другие методы работы с ней мне увы незнакомы. зы. блин на ночь глядя такое читать ...

Вот-вот, именно запросы по 1000 строк писать и не следует. Если почитать основоположников (Кнут, Дийкстра, Кронрод и др.), то станет понятно, что модули должны не превышать 100-200 строк. Ну , это давно писалось, сейчас компьютеры другие, вот и пишутся процедуры на несколько тысяч строк без единой подпрограммы, зпросы сочиняют НЕСОПРОВОЖДАЕМЫЕ другими программистами, да и еще и гордятся этим... Неуд вам, господа! А мои запросы - коротенькие, очевидные, программу понять за четверть часа можно, и работает быстрее...

Написал очередную нетленку из 3-х доков и 2-х отчетов?

В 1С Предприятие, что 7, что 8 все строится из документов,отчетов и т.п. Однако, работать может по-разному. В V8 дурной стиль программирования (по сравнению с V7) укоренился и расцвел не в последнюю очередь благодаря НЕУМЕРЕННОМУ употреблению расширенных возможностей языка SQL, созданных совсем в другую эпоху и совсем не для 1С Предприятия.

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

1С не является реляционной базой данных, здесь модель SQL языка не полностью оптимизирует обработку. Это еще на V7 было заметно. На V8 Они ЗАПРЕТИЛИ (фактически, не по синтаксису) использование методов регистров (Остатки, например, идут на порядок дольше, чем аналогичный запрос - им, что, трудно было подставить там внутренний запрос аналогичный по смыслу?). Кстати, стиль зависит не от языка, а от программиста. Язык 1С очень похож на Паскаль, который в свое время был УЧЕБНЫМ языком и демострировал "высокий штиль". Но необходимость везде использовать язык SQL, которая молодыми программистами воспринимается естественно, делает программы трудночитаемыми и неудобоваримыми! К тому же  в V8 отсутствeет для него отладчик, а также макросредства (хотя бы, как в СИ). В результате меем то, что имеем.

LOL При чем здесь 1С? Какую обработку? Что именно в 77 було заметно? Дальше бред сивой кабылы... "Язык 1С" - уже ржал. В курсе, что 1С - НЕ язык программирования? Дальше диагноз... ЗЫ: явно не трава, что-то посильнее.

, смешались в кучу люди, кони .... (а заодно и классикам теории программирования ни за что досталось) насчет несопровождаемого, несопровождаемого простите кем ? вами ? так боже упаси. а вот мои сотрудники которых я обучал с нуля как то через полгодика навостролись в крупных запросах разбираться. то что вы отнесли базовый функционал языка sql в "расширенные возможности" очень показательно. ваши коротенькие запросы и понятную программку я представить себе могу. у меня есть один клиент который мне достался после, процесса перевода силами одного очень грамотного шпециалиста стиль программирования в 8ке у которого полностью повторял семерочный. "шедевры" спустя полгода еще не все выловил. практически все документы которые были написано в стиле "маленьких" запросов пришлось переписывать заново ибо читабельность кода где вместо одного нормального запроса вытаскивается куча всякой мути а потом перерабатывается силами вложенных циклов ниже нуля. кол-во сделанных ошибок при таком стиле программирования огромен. быстродействие низкое. нагрузка на систему большая. про отчеты я вобше молчу. функциональность нулевая. шаг влево и нужен новый отчет. ну не понимаю я .. если в 8ке дурной стиль программирования то зачем вы ушли от 7ки. зачем вы заочно портите жизнь тем кто после вас придет разгребать ваши "коротенькие запросы и понятные программы", когда вы окончательно добьете конфу и перестанете понимать что делает ваша "коротенькая программка" с 6 вложеными циклами и почему все висит.

" у меня есть один клиент который мне достался после, процесса перевода силами одного очень грамотного шпециалиста стиль программирования" Это автор был!!! 100 процентов!

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

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

желательно посмотреть, что написано в и понять, что речь идет о том, что применение SQL запросов должно быть СТРОГО ФУНКЦИОНАЛЬНО. Пименение ЛЕВОГО соединения и любой другой ОБРАБОТКИ данных в запросе должно быть строго оправдано, а не делаться толко потому, что по-другому не умеешь. Далее, короткий запрос - не только мало строк (если вытаскивается 1000 полей, их нужно перечислить, от этого собственно запрос не удлиняется), а не делающий ничего лишнего (как в примере). Не нужно делать подряд несколько левых соединений, если можно обойтись одним (как в примере). SQL-ное мышление только доказывает одну известную мысль о влиянии языка программирования на стиль мышления разаработчика. Сотрудники Ваши когда-нибудь уволятся, Вы возглавите крупную компанию, систему нужно будет модифицировать, пригласят меня или другого человека, который должен будет вылавливать смысл в очень сложных программах, которые, якобы, очень оптимальны сейчас. И чем больше Вы оптимизируете под дополнительные возможности SQL, тем больше потом заплатит компания. И еще - надо понять, что V7 и V8 (по большому счету) - одна и та же система, точнее, разные ее версии. Это доказывается единством замысла, языка и подхода, а также легкостью переноса объектов из одной системы в другую. К сожалению, многие разаработчики так не считают, прерывая добрую традицию и дико удорожая разработку и сопровождение. V7 и V8 - не являются классическими базами данных, это RAD-системы. Быстрота разработки и сопровождения - здесь главный фактор, оптимальность - на втором месте. Впрочем, оптимальностью в V8 пожертвовали, а ради чего?

В примере показано, что два последовательных запроса В ПРИНЦИПЕ будут работать быстрее, чем исходный один запрос. Их НЕОБХОДИМО здесь делать именно два. При этом второй запрос при ведении суммового учета по складам вообще не выполняется. Об этом речь. Не делайте ничего лишнего, надеясь на оптимальность работы внутреннего механизма SQL в V8 (именно здесь, а не в Oracle, например). Такого рода ошибки могут быть и в других местах стандартных конфигураций, их надо найти и вычистить.

таки не трава, а тяжелая синтетика... Если по существу. Ты нашел криво написанный запрос и оптимизировал. Но выводы отсюда сделал какие-то абсолютно нелепые. Следует из всего только то, что языком запросов в 8 надо пользоваться грамотно. Общеизвестно например, что где возможно использовать ОБЪЕДИНИТЬ ВСЕ и затем СГРУППИРОВАТЬ - работает быстрее чем ЛЕВОЕ (или ПРАВОЕ) СОЕДИНЕНИЕ. Т.е. речь просто о грамотном использовании возможностей языка. А насчет 100-200 строк кода в модулях - ну напиши мне любой типовой отчет (т.е. отчет с такой же функциональностью) в своем стиле. И посмотрим и на его скорость и на количество строк. И все это при условии, что функциональность (гибкая настраиваемость в частности) сохранена...

Стараюсь никогда не переписывать чужой код, тем более, что "полугода" у меня нет для этого - максимум несколько дней. Исхожу из того, что до меня - не дураки работали, стараюсь понять замысел авторов. Вообще, использую метод техника Харлана (Азимов. Конец вечности, рекомендую прочесть). И вообще: чем меньше пишется операторов для решения задачи, тем это решение правильнее.

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

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

Внешнее соединение к табличной части документа очень часто почему-то формирует неоптимальный план запроса. Это известный баг, надо стараться избегать таких внешних соединений.. У меня в ЗУП подобное было. Вылечилось, когда отключил автосоздание статистики в sql, переиндексировал таблицы и сделал вручную sp_updatestats.

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

Спасибо, ценное замечание. Но для меня "очень часто" и даже "иногда" означает "всегда", это средство скопрометировано, я его использовать НИКОГДА не буду.

"пригласят меня или другого человека, который должен будет вылавливать смысл в очень сложных программах" - Ну, тебя точно не наймет. "И чем больше Вы оптимизируете под дополнительные возможности SQL, тем больше потом заплатит компания." - за дятловидность должен платить дятел, а не его работодатель. Не умеешь разобраться в коде - ПНХ. З.Ы. Все еще жду ссылку с

Насчет НИКОГДА вы погорячились :) Вроде как работа над этой проблемой ведется, в тестовой 8.1.11, судя по описанию, изменено индексирование табличных частей..

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

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

Сопровождение после меня, ввиду наличия огромного количество комментариев, большого труда не составляет.

неизлечим...

Попробую таки кое-что объяснить. Во-первых, следует пользоваться общепринятой терминологией, если хотите, чтобы вас поняли. Язык запросов 8 строго говоря не СКЛ. Хотя бы потому, что работает и на файловой версии, когда СКЛя нет вообще. В отличие от СКЛя запросами 8 нельзя обрабатывать данные, можно только выбирать их. Чтобы понять какой бред написан в качестве выводов в прочитайте еще раз хотя бы . Это по форме изложения . Теперь по содержанию. В большинстве случаев выборки данных необходимо получать из разных таблиц системы и некоторым образом их соединять. Альтернатива этому разве что в построении одной таблицы вместо 10, где будут храниться по смыслу разные данные. Но это бред - не взлетит. Не использовать запросы - альтернатива только объектная модель. Но она почти всегда работает медленнее (при наличии фильтров во всяком случае) и позволяет выбрать данные только из одной таблицы. Насколько я понимаю вы против написания больших запросов с использованием разных таблиц в качестве источников. По опыту могу сказать, что получение нескольких выборок (или таблиц значений) из нескольких простых запросов и дальнейшее их соединение в циклах или путем ТЗ.Найти или ТЗ.НайтиСтроки работает на порядки дольше. А написать гибко настраиваемые отчеты как например типовые с полным их функционалом таким образом в принципе нельзя. Что касается сложных запросов - то они самый эффективный инструмент 8, но готовить их нужно правильно. То, что вы не умеете этого делать просто говорит об уровне вашей квалификации. Таки нечего пенять на зеркало, коли рожа крива...  Вывод - учитесь грамотно и эффективно использовать возможности инструмента вместо того, чтобы говорить "он кривой, я им пользоваться не буду"...

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

Не совсем так. 1) Использовать сложный запрос, который выполняется В ПРИНЦИПЕ дольше, чем 2 простых нецелесообразно, особенно когда левое соединение вообще делать не надо в запросе, если оно делается в выборке. Это из точно можно понять. Сложный запрос - не самоцель, тем более, что платформа его выполняет 2 часа, вместо 3 минут на оба простых. 2) Обработка в таблицах, разумеется, вещь долгая. Если не применять очень простую индексацию (20-30 давно отлаженных операторов, которые я всегда использую для случайного поиска в больших отсортированных таблицах) и которая сводит квадратичную сложность к N*logN. 3) А в запросе-то как делается поиск для левого соединения? Случайно, не по базе он бродит? Откуда же такая задержка? 4) По поводу гибких отчетов: только первые 20-30 идут с трудом. Дальше уже будет столько наработок, что изготовить новый займет куда меньше времени, чем в V8 вставить еще одно измерение в регистр Остатки товаров. (Там в модуле регистра есть такой сложный запрос, написанный, вроде мины с защитой от разминирования). 5) И потом: в V7 тоже есть запросы. И используются в каждом отчете. Но жить не мешают: можно и остатками и движениями регистра подвигать. Что же в V8 случилось, что эти методы не работают, хотя и опубликованы? Получается, что в V8 запрос - не инструмент, а чемодан без ручки - и тащить тяжело, и бросить жалко, точнее - невозможно. Особенно умиляет, когда, находясь в контексте, например, Перемещения, делается запрос, чтобы получить Склад. 6) И проблема не в моих собственных запросах. А в тех, которые приходится исправлять в стандартных и нестандартных конфигурациях, причем иногда выигрыш происходит на порядок.

Что ж Вы так переживаетеп о поводу ссылок на ? Написано вполне обычно. Уверен, что сможете написать гораздо лучше, если на часок отключитесь от Интернета...

после приобщения к нетленке особо радует, что, оказывается, ЛЕВОЕ СОЕДИНЕНИЕ - это обработка данных :)

- 2 пункт. Я правильно понял, что вы на восьмерке свой квиксорт пишете каждый раз? ^^

По поводу обработки данных в запросе V8 - это Вы объясните, который ухитряется  delete insert делать... Что же касается "ненастоящего" СКЛ, то об этом-то я и твержу все время. Кстати, большинство моих клиентов работают на обычной файловой версии, и пользователе у них с десяток. Им и невдомек, что V8 им вообще не нужна, вполне семеркой обошлись бы... Но те ребята, которые им V8 продали, давно "растаяли в тумане дымкою..."

Метод поиска в таблице (двоичный поиск, алгоритм в Кнуте посмотрите) работает на любой платформе. Применяю на V7. На V8.1, кажется, появилось штатное средство. В случае, описанном в его применение позволит сократить секунд 20-30, поэтому - нецелесообразно. Quicksort не пишу, а SHELL - приходилось: впрочем, это было на довольно древних машинах, про которые современные программисты могут в летописях почитать...

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

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

SQL (Structured Query Language) в V8, разумеется, настоящий (точнее, подмножество настоящего). Он есть и на файловой и на серверной версии. Вот база данных - не настоящая. На файловой версии - она вообще самописная с неизвестной (мне, по крайней мере) структурой. В серверной версии этот язык как-то транслируется в запросы к СУБД SQL. Как - мне тоже доподлинно неизвестно, возможно, и с ошибками "...кое-где у нас порой...". Для программиста существует только язык SQL, результаты интерпретации которого в файловой и серверной версии не должны отличаться (кроме длительности исполнения).

хоть квиксорт, хоть бинарные поиски... Право же, Кнут развращает неокрепшие умы :)

Не бойтесь, почитайте - полезно.

За весь свой опыт работы с запросами я знаю только 3 причины, по которым запрос может выполняться долго. 1. Запрос криво написан (самая частая причина). 2. В таблице-источнике нет нужного нам индекса. 3. В базе нет таблиц для удобного получения нужных данных. Все три причины решаются в конфигураторе совершенно спокойно. А насчет только 20-30 первых идут с трудом - полная хня. Своим способом вы не напишите ни одного с функционалом и гибкостью настройки типовых отчетов. Вот когда напишите хоть один такой - приходите, поговорим предметно...

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

Тссс... тихо! Еще б консоль ему сдал

это абсолютно безопасно. Он невменяем...

В подробно описано: запрос не слишком оптимальный по форме, но ведь работает в 99% случаев. А вот в одном документе (так, видимо, данные подобрались) - сваливается в двухчасовую обработку. Такой пример разаработчикам, разумеется, для отладки подобрать сложно... Я их и не виню за это. Мне-то что делать? На линию кончсультаций писать? Ждать следующего релиза? Нет! Оптимизировать запрос, отказавшись от соминительного левого соединения, которое вообще ЛЕГЧЕ сделать "ручками", чем разбираться с разаработчиками! А на будущее: стараться не применять скомпрометировавшее себя соединение вообще. Не очень понимаю, в чем тут вообще предмет для возражений. Меня ведь никто не может ОБЯЗАТЬ писать запросы именно так, как пишут их авторы конфигураций? И еще: а может, настало время попристальнее посмотреть, почему так медленно, например выполняется Карточка счета за один день по одному товару на одном складе, когда в результате в листинге появляется 10 строк, а ждать этого на серверной базе нужно минут 10 (на файловой вообще не могу дождаться)?

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