1C-ники начинают думать

[Сисой]

В последнее время в инфопространстве 1С начали появляться материалы, изучающие вопросы эффективности того или иного алгоритма в рамках 1С. Это уже радует.
Вот например, изучение эффективности разузлования спецификаций:
http://nashe1c.ru/materials-view.jsp?id=357

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

[EVGL]

Начиная с 4.0 - стопроцентно рекурсивный.

[Reaper]

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

[ibc]

Всегда думал, что мешает на 1С8 написать народное ERP, к примеру, как написали Wiki-педию?

[Индра]

Не знаю, может не в тему. Была у меня частная задача - в отчете посчитать плановую себестоимость продукции, когда известна покупная цена сырья. Реализовал целиком на SQL в одной хранимой процедуре. Несмотря на поддержку рекурсии в SQL, я от нее отказался - ведь не было задачи получить список сырья, надо было получить только цифру стоимости. Сделал так - выгрузил все (то есть вообще все) строки BOM во временную таблицу, добавив служебные поля, и запустил итеративный цикл вычисления себестоимости ГП/ПФ на основании строк (при условии что все строки имеют непустую себестоимость). При первом проходе стоимость могли получить только ПФ 1-го уровня, при втором проходе - ПФ 2-го уровня, и так далее. Цикл останавливался, когда очередная итерация не производила ни одного update - это означало что все, что можно вычислить - вычислено. Далее из полного массива ГП выбирал только интересующие позиции (в моем случае join с прогнозом продаж). На объеме порядка 20 000 строк BOM, расчет выполялся считанные секунды. Еще раз убедился, что итерации с последовательным приближением - быстрее рекурсии, да и по вычислительным ресурсам более прогнозируемо. Если кому интересно - могу подарить расчет. Там еще учитывались технологические отходы, потери сырья, и вторым проходом распределялись FIC - тоже в SQL. В итоге получались несколько составляющих себестоимости - материальная и полная. Конечно, код немного специфичен для заказчика, и поскольку полностью отсутствуют циклы по курсорам (все реализовано матричными операциями на чистом SQL), код не вполне очевиден, зато фантастически быстр. Я люблю SQL...

[Ish_2]

1c-ники начинают думать ! Кхы..кхы.. я воспринял это как похвалу.
Как автор статьи по ссылке http://nashe1c.ru/materials-view.jsp?id=357
замечу , что на самом деле указанный алгоритм (принципиально нерекурсивный) может быть с легкостью реализован "чисто" на SQL. Т.е. речь идет об общем подходе к решению задач разузлования , а не об эффективности алгортимов на платформе 1с.
На мой скромный взгляд,
для графов с количеством узлов более миллиона и при абсолютном контроле зацикливания альтернативные рекурсивные алгоритмы, предполагающие "ручной" кодинг ( "хоть на чём") проиграют и проиграют много.

[Ish_2]

Цитата:

Не знаю, может не в тему.

Почему же - в тему. Правда, приходится догадываться об исходных данных и самой задаче.
Если ПФ - это полуфабрикат или сырье.
А исходная таблица для всех специфивкаций предприятия имеет 3 колонки :
РодительПФ , РебенокПФ , Количество
То тогда понятно , что хранимая процедура это запрос в цикле.
И мы получаем поуровневый обход графа. ПФ1,ПФ2 и т.д.
Что мы при этом высчитываем не так важно.

Так вот представьте , что у Вас в исходной таблице 1 000 000 строк , уровней графа -20 , возможны зацикливания и вы в своей хранимой процедуре ОБЯЗАНЫ не просто отбрасывать (игнорировать) зацикленные ветки (Родитель является ребенком) , но и представить пользователю работающему со спецификациями удобный интерфейс для исправления ошибок зацикливания .
Возможно, Ваш взгляд на саму эту задачу и достигнутые Вами фантастические скорости изменится самым радикальным образом.

[Reaper]

1 000 000 строк ладно, но вот 20 переделов - хотел бы я в таком проекте поучаствовать

[Ish_2]

По указанной ссылке можно скачать файл обработки , содержащей создание как раз такого тестового примера (1 000 000 строк, 20 уровней) для конфигурации БП2.0(1.6).