Мини-обзор разных решений задач

18.04.24

Разработка - Математика и алгоритмы

Три задачи - три идеи - три решения. Мало кода, много смысла. Мини-статья.

Всем привет!

Сегодня будет необычный кейс - будут представлены решения трех задач.

Задача 1

Задача 1 - поиск документов по номенклатуре (в другой формулировке - поиск документов по контрагенту, позже решил подобную задачу поиск документов по сотруднику).

 
 Разные способы решения - можно пропустить

Встает задача - как ускорить поиск. Решил оптимизировать решение так - сначала запускаю в конфигураторе по номенклатуре (контрагенту или сотруднику) "Поиск ссылок на объект" - копирую полученный результат в табличный документ обработки - далее запрос формирую динамически во время обхода строк табличного документа (рис. 1, 2, 3 - в ленте). Подходит для ОФ и УФ.

 
 Рисунки 1, 2, 3 - наглядный пример ускорения алгоритма поиска
 
 Небольшой код, который позволяет динамически формировать запрос по строкам табличного документа

 

Задача 2

Задача 2 - имеется динамический список номенклатуры - только для ОФНужно на форме списка реализовать два отбора: отбор по остаткам - то есть показывать "только в наличии", и отбор по брендам (или по производителям, у кого как).

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

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

 
 Небольшой код для записи поля Ссылка2

 

Задача 3

Имеется Файловая база 38 Гб - доработанная УТ 10.3 (рис. 5, 6).

 
 Рисунки 5 и 6

Когда она перестанет открываться - неизвестно. Еженедельный анализ размеров таблиц показывает, что таблица "Товары" документа "РеализацияТоваровУслуг" растет быстрее всех - это первая строка сверху на рисунке 6Задача 3 - спасти базу.

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

Третий способ - как временный способ - и как часть процесса будущей свертки - очистить таблицу Товары в документах РеализацияТоваровУслуг (за определенный период) с запретом на перепроведение этих документов. 

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

Вот это можно использовать: для 2017 года можно написать обход этих процедур (рис. 8, 9).

Далее я проверил, чтобы в процедурах ПередЗаписью() и ПриЗаписи() стояла проверка на режим обмена данных загрузка - это позволит при удалении таблицы Товары записывать документ Реализация товаров и услуг в режиме ОбменДанными.Загрузка = Истина (рис.10, 11) - чтобы не выполнялись никакие другие проверки.

Перепроведение документов в этом периоде 2017 года также запрещено стандартным механизмом "Датой запрета редактирования".

Еженедельно таблица товаров реализаций росла на 36 Мб, при таком темпе таблица достигла бы лимита в 4Гб через 2-2,5 месяца. Таким способом получилось удалить товары за период 2017-2019 включительно, освободить 1Гб этой таблицы, отсрочить переполнение таблицы почти на 7 мес.

Таблица по регистру накопления НДС-начисления (итоговая) растет с темпом 1Мб в неделю, поэтому не критично для ситуации в целом. Таким способом можно начать первый этап свертки больших файловых баз, работа в которых происходит в режиме 24х7. 

В дальнейшем я развил мысль удаления табличных частей у документов - и реализовал свертку подокументно. О чем описал в статье Свертка базы УТ 10.3. Новая концепция.

 
 Рисунки 7, 8, 9, 10, 11
 
 Небольшой код, который позволит удалить Товары из Реализации

На этом все. Всем добра!

С пользой для клиентов, Рустем

См. также

Метод Дугласа-Пойкера для эффективного хранения метрик

Математика и алгоритмы Платформа 1C v8.2 Конфигурации 1cv8 Россия Абонемент ($m)

На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.

1 стартмани

30.01.2024    2034    stopa85    12    

34

Алгоритм симплекс-метода для решения задачи раскроя

Математика и алгоритмы Бесплатно (free)

Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.

19.10.2023    5038    user1959478    50    

34

Регулярные выражения на 1С

Математика и алгоритмы Инструментарий разработчика Платформа 1С v8.3 Мобильная платформа Россия Абонемент ($m)

Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.

1 стартмани

09.06.2023    8178    5    SpaceOfMyHead    17    

59

Модель распределения суммы по базе

Математика и алгоритмы Платформа 1С v8.3 Россия Абонемент ($m)

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

1 стартмани

21.03.2022    8100    7    kalyaka    11    

44

Изменения формата файлов конфигурации (CF) в 8.3.16

Математика и алгоритмы Платформа 1С v8.3 Бесплатно (free)

Дополнение по формату файлов конфигурации (*.cf) в версии 8.3.16.

16.12.2021    4692    fishca    13    

37

Интересная задача на Yandex cup 2021

Математика и алгоритмы Бесплатно (free)

Мое решение задачи на Yandex cup 2021 (frontend). Лабиринт. JavaScript.

12.10.2021    9128    John_d    73    

46

Механизм анализа данных. Кластеризация.

Математика и алгоритмы Анализ учета Платформа 1С v8.3 Анализ и прогнозирование Бесплатно (free)

Подробный разбор, с примером использования, встроенного механизма кластеризации 1С.

31.08.2021    8241    dusha0020    8    

72
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Darklight 32 06.04.23 13:10 Сейчас в теме
К третье задаче не хватает ещё варианта решения: разобраться с помеченными на удаление элементами (конечно не знаю как у вас, но обычно у таких баз такая проблема весьма актуальна и её решение не всегда тривиально) - найти причины их удержания от удаления и устранить - или снять пометки. Обычно вместе с элементами справочника так удаётся вычистить и документы (в т.ч. ранее не помеченные к удалению - удалить) и связанные регистры.

Ещё один момент - это чистка транспортных документов (обычно это взаимодействие с ЭДО, напрямую или косвенно - а-ля взаимодействие с внешними системами) и прочих документов (порой справочников) - старые обычно нафиг не нужны и сами не удаляются. Но если такие процессы взаимодействия на предприятии есть (например общение, в т.ч. по эл. почте).

Ещё одним нюансом для многих (но не для всех) может являться чистка управленческого учёта (особенно если его данные нафиг не используются, но ведутся) - тут не сложно выявить упр. регистры и (по желанию) получить их остатки - сформировать документ их ввода, а потом безжалостно очисть все движения на опр дату. Обычно это не занимает много времени (на разработку) - за неделю управиться можно (в идеале за день-два на копии + 1 день на продуктовой + время на выполнение обработок - это уже от объёма баз зависит);
аналогично можно поискать ещё и прочие оперативные регистры - которые важны только здесь и сейчас и нафиг сплющились в прошлых периода.
Например регистры сведений "Списанные товары".

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

Ну а ещё обратите внимание на прикреплённые файлы (Справочник "ХранилищеДополнительнойИнформации" и ему подобные, в зависимости от конфигурации, в т.ч. Справочник "ЭДПрисоединенныеФайлы", если, конечно, по старинке храните файлы внутри ИБ) - там зачастую зависает лишнее (объектов уже нет, а файлы есть, или наоборот - объекты помечены на удаление, а файлы мешают их удалить) - это всё тоже легко чистится!
2. RustIG 1631 11.04.23 10:47 Сейчас в теме
(1) Павел, все намного печальнее оказалось.
Есть регистры накопления (итоги), которые под завязку заняли место - размер этих таблиц приблизился к 4 Гб, и с каждой неделей приближается. На рисунке это видно. Была попытка почистить заказы по закрытой организации - при распроведении заказов и связанных ЗакрытийЗаказовПокупателей - по времени занимает половина дня - ночи не хватает, чтобы завершить процедуру к утру - параллельно 20 фоновых заданий обменов - параллельно 15 пользователей работают - так вот итоговый регистр накопления ЗаказыПокупателей (Итоги) переполняется - уже не осталось свободного места для всяких маневров, чтобы что-то урезать или распровести или удалить...Единственный выход в подобных ситуациях - переходить на клиент-серверный режим.
3. RustIG 1631 11.04.23 18:43 Сейчас в теме
(2) Ходил в размышлениях пару дней - думал, почему итоговая виртуальная таблица ЗаказыПокупателей при распроведении заказов растет?!
Во время описания итогового отчета о выполненных работах понимание пришло. Есть документы, которые пишут "приход" в регистр, есть документы , которые пишут в регистр "расход", если имеются ненулевые остатки, то они попадают в итоги (виртуальную таблицу).
Отсюда большой вывод - распроведение желательно проводить поочередно - сначала документ прихода, затем документ расхода, затем снова по кругу - документ прихода, затем документ расхода.
При этом на время групповой обработки документов желательно отключить "Пересчет итогов".... Хотя это спорно, поскольку после включения процесс пересчета может надолго затянуться. И так как частичное распроведение зачастую происходит в рабочей базе в рабочее время - ночи не хватает, то "Пересчет итогов" лучше не отключать совсем.
5. RustIG 1631 12.01.24 07:59 Сейчас в теме
(3)
Отсюда большой вывод - распроведение желательно проводить поочередно - сначала документ прихода, затем документ расхода, затем снова по кругу - документ прихода, затем документ расхода.


Вышло продолжение статьи по теме свертки базы - Свертка базы. Новый взгляд
4. RustIG 1631 11.04.23 19:07 Сейчас в теме
Кому интересна тема свертки - прошу сюда - много нюансов описано https://infostart.ru/marketplace/1033813/
6. xlmel 27.01.24 13:30 Сейчас в теме
У одних моих клиентов на PostgreSQL таблица итогов регистра Заказы покупателей разрослась до 43 ГБ. Когда сделал запрос к ней с отбором по документу, то увидел причину. Заказ ставил ставку НДС БезНДС, а реализация НеНДС. Оказалось, что по умолчанию Заказ покупателя ставит такую ставку, если не установлен флаг Учитывать НДС, и при этом не важно, что в строке Товары. То же самое и документ Реализация - ставит по умолчанию НеНДС. Поэтому простой обработкой для всех для всех заказов покупателя, у которых не установлен флаг Учитывать НДС я установил этот флаг, в табличной части товары установил ставку НДС НеНДС и провел заказы. Обрабатывалось очень долго (порядка 750 заказов в час), после этого запустил ТИС пересчет итогов и теперь размер таблицы итогов редко превышает 100 Мб. Вполне возможно, что и у Вас похожая проблема.
7. RustIG 1631 12.05.24 19:44 Сейчас в теме
(6)верно, примерно было так. Первый большой регистр (таблица) это табличные части товаров. Второй по размеру это регистр ндс по документу Формирование записей книги покупки. Виртуальные итоги которого росли за счет того, что документа -антагониста не было. Первый документ делал движения в плюс, не было ни одного документа, делающего движения в минус. И третий по размерам регистр, который рос бесконечно это взаиморасчеты с контрагентами по документам расчетов, который никогда в ноль не выйдет из-за измерения ДокументРасчетов. Скажем так, если долгов по договору в целом нет, то по документам расчетов они будут всегда. Понять причину неадекватного роста базы, когда базу видишь впервые, да и с подобной задачей столкнулся впервые - понять за короткий срок причину и что предпринять - задача не из простых. Табличную часть товаров я почистил. Но можно ли так делать системно и систематически большой и открытый вопрос. Недавно я его закрыл для себя - придумав способ свертки подокументно. Регистр по ндс легко почистил распроведением документов. А вот что делать с регистром взаиморасчетов по документам расчетов до сих пор неясно.
Оставьте свое сообщение