В УТ 11 такой пакетный запрос при расчете скидок. Который сейчас крайне медленно работает. Они издеваются что ли? Больше запрос кто то видел?

Это где такое?

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

(0)[ Они издеваются что ли]
нет
[Больше запрос кто то видел?]\
да

Я писал в 50 000 строк с 7 параметрами на 8.0
Запрос летал.

(0) Нет. Если это действительно так, то налицо, имхо, ошибка проектирования.

Проголосую.

От кого шифруетесь, господа?

(0) В ЗУПе есть что-то сравнимое

Для 1С это нормально, а так, конечно, это изврат...

(0) Выложи текст запроса.

(0) А сколько временных таблиц? Укажи версию и в каком модуле/процедуре.
(9) Гы-гы.

(2) УТ 11.0.9.8 Общий модуль СкидкинаценкиСервер процедура РассчитатьДеревоСкидокНаценок(ПараметрыРасчета, ВходныеПараметры) где то здесь он собирается.

(10) там 200 с лишним пакетов у меня в запросе.

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

Циклом что ли собирается?
Видел такое в Бух КОРП при определенных условиях падало на ограничении в 256 таблиц.

(14) да есть там цикл какой то. Видимо размер запроса зависит от количества применяемых скидок и условий по ним. У нас скидок 30 и условий скидок 30.

Выкладывай прям сюда, положим хостинг :)

это издевательство

(13) +1

Полезное хоть что делает? Что возвращает?

Я делал всякие заморочки, все укладывалось обычно в пару страниц текста на T-SQL. У разработчиков, видать, уже крыша поехала.

шаблон RLS в документообороте боле 10 000 строк....

я писал об этом примерно 3 года назад... http://infostart.ru/public/87912/

при том это RLS оно вызывается практически постоянно :)

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

(21) правильная рекомендация. спасает от геморроя в сопровождении.

теперь это головная боль.

(20) В УТ11 то же самое в рлс

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

(20) в ДО это пофиксили. С появлением дескрипторов РЛС стали по большому счету даже читаемыми.
Правда там все равно инопланетянство с доступом, но стало полегче - пользователи добавляются за конечное время хотя бы

(0)Это ты еще в УПП не ковырял, там такого, особенно в блоке расчета заплаты, валом.
ДВА Оракла пишут и поболее.

Если он интуитивно понятный и быстро работает, то...

чем дальше, тем дурнее

Чем больше строк, тем больше денег

(30) Откуда? При нормальной структуре модуля/запросов добавить фигулинку - 15 минут. "Округляем", получаем 1час. Заказчек доволен.
Когда запрос на 100500 строк, ту же фигулинку добавить - надо сначала часов 10, чтобы разобраться - что это, как в "это" вписать, притом, чтобы "это" не поломать.
Заказчек возмущен.

(30) это у амеров, в россии чем меньше тем больше денег)))

(30) за всякую индускую лапшу денег не платят

(15) т.е. у вас такой бардак в ценообразовании, а виноват динамический запрос? ;)

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

https://dl.dropboxusercontent.com/u/64196148/8f2f449da312.jpg

и да

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

>Больше запрос кто то видел?

rls в БСП... чудо враждебной техники

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

(40) Т.е. вы всерьез предлагаете 1С писать в типовых запросы в которых бы глюки и медленнодействие легко обнаруживались :)

(0) Это он с разработчиком ЗУП дружит наверное...
Я бы взял их обоих... и ..Хотя расстрелять - это слишком легко

(0) Предложите более быстродействующий вариант.

(0)
У меня есть штатные запросы с десятками параметров, 400-500 временных таблиц. Строк запроса несколькот тыщ
Работает крайне быстро (относительно конкурирующих решений)

Медленно не от того, что 70 параметров, а от узкого места, которое искать надо

(3)Я писал в 50 000 строк с 7 параметрами на 8.0
- сказочник. в УПП около 1 млн строк, в УТ и подавно меньше.

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

(44)+
естественно запросы формируются динамически, а не вручную 5000 строк кода

по рукам

Большой не значит плохой!

Конечно плохо, а если что-то сломается (люди же запрос пишут, могут что-то не предусмотреть) - как чинить? Конечно, все будут отлаживать, работать-то нужно - но это же гемор жуткий. Он хоть конструктором открывается? Если как в ЗУПе там какие-то вставки текста посреди запроса - то это полное неуважение...

P.S. Интересно, как они сами такие запросы тестируют перед релизом программы

(0) Что, ни разу ЗУПовских запросов на 200 кБ не видел?

(35) Так и пиши: "дурим покупателей, чтобы никто ничего не понял". Покупателю "гибкая система" не нужна. Ему надо так: "Скидка 20%" - на все.

(53) Ты кто? Про маркетолог?

(54) Всех маркетологов надо согнать в одно место и сбросить со скалы. Они - источник заразы под названием копроэкономика.

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

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

Интересно, в чем они разрабатывают такие запросы =)

(58) то что у них есть какая то консоль запросов недоступная простым смертным - это факт.

(59) А зачем какая-то консоль? Просто готовишь кусочки и собираешь потом из них конечный запрос. Просто надо уметь программировать - так, чтобы написал код, и он с 1-2 запуска работал без ошибок.

Когда для решения задачи больше подходят матричные вычисления это

всему виной мне кажется героин

Это все проблемы давления соленых растворов в головах скидкотолог0ff.

Отличная голосовалка! Вот и определились, кто нормальный, а у кого ....

нормальных людей на мисте больше
радует

(60) ненавижу когда запрос собирают из кусков и когда вызов консоли запросов не срабатывает.  Постоянно крою матом тех кто так делает.

(66) есть простой workaround -- найди место вызова функции Выполнить() и забери у запроса текст.

Запрос в 8000 строк.... Теерь ты видел больше

(66)Из кусков имеется ввиду из ВТ я так думаю... и всё срабатывает..
И в зупе нет запросов на 8к строк.. большие - да, но на 8к строк нет мне кажется..

(0) не только видел, сам писАл такие

(66) Как ты понимаешь, если чел пишет без консоли - ему без разницы, открывается запрос в консоли или нет. Но ничто не мешает и в этом случае сделать все 1 строкой, чтобы он открывался в консоли.

(11) Прогонял я когда-то отладчиком эту процедуру -- жестокая вещь.

А так ответ в (44) -- тормозить может от какого-то одного соединения, а не от того, что запрос на 8к строк.

(72)
+1
Я такие запросы исследовал методом бинарного деления.
Запрос делится на 2 части(или несколько).
Замеры : Выполнить 1 и Выполнить 2
Потом в проблемную часть еще на 2 .
И так пока не выявится самый вложенный проблемный запрос

Выявленый проблемный запрос тупо был построен так, что не попадал в индекс

если платят по 1 тр за строку, то

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

(73) А что делать, если отдельно обе части выполняются быстро, а вместе - медленно? ;)

В консоли запросов ИР кстати есть команда "Выполнить все подзапросы" http://devtool1c.ucoz.ru/_si/0/50350575.jpg
В колонке "Длительность чистая" дерева запроса при этом вычисляется грубое время выполнения каждого узла дерева как длительность выполнения самого узла минус сумма длительностей выполнения всех непосредственных дочерних узлов.

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

(77) Ну тут уже только анализ плана запроса поможет.