Списание партий по FIFO одним запросом #593563

Вот запрос. Смысл - одним запросом рассчитать количество к списанию в разрезе партий по множеству номенклатуры. На выходе только товары, по которым достаточно партий. Просьба проверить - все ли корректно работает. ВЫБРАТЬ               РегистрНакопления.Партии.Остатки(               ВТ1.Партия,

хм, дежавю пару за сегодня раз видел подобную тему ...или это резюме?

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

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

Зачем хотите именно в запросе рассчитать партии списания? Не проще ли это делать уже в модуле. И писать проще, и для системы легче.

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

Лисапед. Штатные механизмы ужо не канают, нам бы тоже самое, но с квадратно-перламутровыми?

не скрою что был еще спортивный интерес :)

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

а партии чтоб не залеживались надо быстро пускать в расход :)

Проверено. Факт. Железобетонный. Медленнее минимум в 1.5-2 раза. Транзакция растягивается, конфликты блокировок множатся. Автора лишают премии.

Нет, ну в свое время @Ненавижу1С проявлял теоретический интерес к возможности решения СЛАУ запросами. Здесь, можно сказать, тот же случай :)

верю :)))

ну не всеж только рутина в обмен на премии :) хочется эдакий изврат забацать тормоза проверю на выхах - надо выбрать базу для насилия

Завтра проверим ;)

кстати соединения производятся временной таблицей на саму себя может и не будет падения производительности завтра нельзя - нащальника строгая :))) ;)

Так и 1Сники проявляли. Не взлетело.

это кто такие ? разработчики платформы?

Доказано теоритически что партионка расчитывается на SQL только курсорами а стало быть смысла писать одним запросом нет.(проще на клиенте в цикле) Конечно может чего нибудь в 1С на сервер приложений намудрили с кешированием но это врядли.

Ничего не мутили. Я по глупости когда 8-ку осваивал проверял. Списание силами сервера приложений делает супермегазапрос как стоячего.

наверное мой уровень не позволяет мне понять что Вы написали поясните - как чего стоячего? как выяснили что делает супермегазапрос ?

наверное не в теории смогу проверить только сам что там в результате будет мегастоять

если приложение управляемое, то лучше все-таки запросом, имхо

только 8.2, только на сервере и только запросом аминь :)

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

в типовых ошибки находил - бывало но суть не в том - знаю я или не знаю типовой подход суть в

год рождения указан в нике

Это ты сейчас кого теоретиком обозвал? Если ты не знаешь в какую позу поставишьь СУБД соединением таблиц по условию типа ">=" по дате - флаг тебе в руки, барабан на шею...

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

в простых случаях запрос быстрее

подскажите пример сложного случая - я его воссоздам

на Исе поищите - обсуждались эти вопросы вроде активно... или я туплю - может и здесь было...

Тут целых 4 запроса вместо 1

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

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

скуль это другая песня :) с прямыми запросами в семерке работал, но непосредственно в самом скуле мало писал я слышал что там можно организовать рекурсивность запроса - а это новые возможности для закура сейчас работаю с 8.2 и интересно ее мощами реализовать, не выходя за рамки ограниченности ее платформы

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

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

Иса - инф0старт

спасибо - почитаю по этой теме

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

буду готовить базу - проверю скорость типовым подходом и пакетным запросом

Вот нашел на ИСЕ нечто похожее

списание партий в типовой - это сложный случай

и, наверное, прав.

Надо бы на NuLL проверить еще...вроде бы не забыть.

а разве моменты времени сравниваются на >= ? Что-то я пропустил.

тестовая база создана случайным образом 2000 уникальных товаров 30000 партийприходов 3500 расходов - больше создать терпения не хватило число строк товаров 1..50 проведение таким запросом не вешает базу поправлю позже алгоритм подбора партий чтобы списывалось все количество сразу а не частями как сейчас так как это долго происходит при таком количестве партий впереди тестирование общепринятого алгоритма списания и одним запросом

плата за универсальность этого механизма мне показалось что это семерочный подход или я не понял высказывание товары соединяются с партиями внутренне и товары только те на которые есть остатки в принципе проверку на недостаток партий допишу - это + запрос в пакет еще как сравниваются!

да и платформа 8.2 - база SQL

, При соединениях, тем более внутренних принято проверять значения полей на значение NULL, Иначе такие выражения в запросе как   СУММА(ВТ2.Остаток) - ВТ1.Остаток КАК ПредыдущийОстаток, дадут совершенно непредсказуемый результат, точнее не дадут вооще. даже если есть Вт2.остаток

o_O NULL никак не может получиться при _внутреннем_ соединение...