31.01.2011, 19:17 | #1 |
Участник
|
1C-ники начинают думать
В последнее время в инфопространстве 1С начали появляться материалы, изучающие вопросы эффективности того или иного алгоритма в рамках 1С. Это уже радует.
Вот например, изучение эффективности разузлования спецификаций: http://nashe1c.ru/materials-view.jsp?id=357 Вопрос к спецам по производственному модулу Аксапты - там какой алгоритм применяется? |
|
31.01.2011, 19:48 | #2 |
Banned
|
Начиная с 4.0 - стопроцентно рекурсивный.
|
|
31.01.2011, 20:16 | #3 |
Участник
|
Талантов всегда хватало. Толку мало - в типовых конфах все топорно, полное разузлование выполняется реккурсивно. Для меня теперь головная боль - делаешь инструмент и если заякориваешь его на заложенный в конфигурацию механизм, то получаешь тОрмоза, в котором 90% времени занимает типовое разузлование. Делаешь собственное разузлование - все летает, но придется постоянно следить за типовой, чтобы при обновлениях не потерять совместимость. Вот и развернись тут.
|
|
03.02.2011, 12:52 | #4 |
Участник
|
Всегда думал, что мешает на 1С8 написать народное ERP, к примеру, как написали Wiki-педию?
|
|
08.02.2011, 19:16 | #5 |
Участник
|
Не знаю, может не в тему. Была у меня частная задача - в отчете посчитать плановую себестоимость продукции, когда известна покупная цена сырья. Реализовал целиком на SQL в одной хранимой процедуре. Несмотря на поддержку рекурсии в SQL, я от нее отказался - ведь не было задачи получить список сырья, надо было получить только цифру стоимости. Сделал так - выгрузил все (то есть вообще все) строки BOM во временную таблицу, добавив служебные поля, и запустил итеративный цикл вычисления себестоимости ГП/ПФ на основании строк (при условии что все строки имеют непустую себестоимость). При первом проходе стоимость могли получить только ПФ 1-го уровня, при втором проходе - ПФ 2-го уровня, и так далее. Цикл останавливался, когда очередная итерация не производила ни одного update - это означало что все, что можно вычислить - вычислено. Далее из полного массива ГП выбирал только интересующие позиции (в моем случае join с прогнозом продаж). На объеме порядка 20 000 строк BOM, расчет выполялся считанные секунды. Еще раз убедился, что итерации с последовательным приближением - быстрее рекурсии, да и по вычислительным ресурсам более прогнозируемо. Если кому интересно - могу подарить расчет. Там еще учитывались технологические отходы, потери сырья, и вторым проходом распределялись FIC - тоже в SQL. В итоге получались несколько составляющих себестоимости - материальная и полная. Конечно, код немного специфичен для заказчика, и поскольку полностью отсутствуют циклы по курсорам (все реализовано матричными операциями на чистом SQL), код не вполне очевиден, зато фантастически быстр. Я люблю SQL...
Последний раз редактировалось Индра; 08.02.2011 в 19:35. |
|
13.02.2011, 11:21 | #6 |
Участник
|
1c-ники начинают думать ! Кхы..кхы.. я воспринял это как похвалу.
Как автор статьи по ссылке http://nashe1c.ru/materials-view.jsp?id=357 замечу , что на самом деле указанный алгоритм (принципиально нерекурсивный) может быть с легкостью реализован "чисто" на SQL. Т.е. речь идет об общем подходе к решению задач разузлования , а не об эффективности алгортимов на платформе 1с. На мой скромный взгляд, для графов с количеством узлов более миллиона и при абсолютном контроле зацикливания альтернативные рекурсивные алгоритмы, предполагающие "ручной" кодинг ( "хоть на чём") проиграют и проиграют много. |
|
14.02.2011, 14:26 | #7 |
Участник
|
Цитата:
Не знаю, может не в тему.
Если ПФ - это полуфабрикат или сырье. А исходная таблица для всех специфивкаций предприятия имеет 3 колонки : РодительПФ , РебенокПФ , Количество То тогда понятно , что хранимая процедура это запрос в цикле. И мы получаем поуровневый обход графа. ПФ1,ПФ2 и т.д. Что мы при этом высчитываем не так важно. Так вот представьте , что у Вас в исходной таблице 1 000 000 строк , уровней графа -20 , возможны зацикливания и вы в своей хранимой процедуре ОБЯЗАНЫ не просто отбрасывать (игнорировать) зацикленные ветки (Родитель является ребенком) , но и представить пользователю работающему со спецификациями удобный интерфейс для исправления ошибок зацикливания . Возможно, Ваш взгляд на саму эту задачу и достигнутые Вами фантастические скорости изменится самым радикальным образом. Последний раз редактировалось Ish_2; 14.02.2011 в 14:31. |
|
14.02.2011, 14:41 | #8 |
Участник
|
1 000 000 строк ладно, но вот 20 переделов - хотел бы я в таком проекте поучаствовать
|
|
14.02.2011, 14:45 | #9 |
Участник
|
По указанной ссылке можно скачать файл обработки , содержащей создание как раз такого тестового примера (1 000 000 строк, 20 уровней) для конфигурации БП2.0(1.6).
|
|
|
|