Комментарии
Избранное
Подписка
Сортировка:
Древо
Отличное оформление!
Для полноты картины добавлю пару ссылок:
1) - описание не такое детальное и наглядное, но задача та же и условие соединения в запросе чуть проще. Кстати, в комментарии к той статье дается оценка быстродействия запросного метода. Она совсем не такая оптимистичная, как в этой статье, но на примере списания остатков заказов этого заметно не будет. Также в комментарии приведен рисунок - ментальная модель, используемая при синтезе запроса. Это два стоящих рядом столбика приходов и расходов, общие отрезки в которых и образуют результат. Двумерная модель транспортной задачи, приведенная в данной статье, очевидно, нагляднее.
2) - также говорится об использовании аналогии между списанием по партиям и транспортной задачей, правда для скорости она решается не запросом, а программно. Обратите внимание на скриншоты хода решения задачи - они очень похожи на рисунки из статьи.
Ну и остались вопросы по постановке задачи. Что-то из серии "угадал все буквы, но не смог назвать слова" (это я про себя). Понятно, когда есть несколько заказов и требуется закрыть их одним поступлением. Тогда закрываем их по ФИФО. Например, заполняем товары и количество, затем запускаем обработку заполнения табличной части и она разбивает строки по заказам. То есть запрос в ОЗТЧ? Но почему не свернуть ТЧ по одинаковым товарам перед вызовом ОЗТЧ. Это ведь сам подбор делает (серии?). Как кладовщик решает, что заказа нет? В этом случае оформляет ордер? В какой момент на ордер поступление делается? То есть непонятна роль ордера и причины возникновения строк с одинаковым товаром. Или обработка одним запросом сразу много поступлений обрабатывает? - Разъясните, пожалуйста!
Для полноты картины добавлю пару ссылок:
1) - описание не такое детальное и наглядное, но задача та же и условие соединения в запросе чуть проще. Кстати, в комментарии к той статье дается оценка быстродействия запросного метода. Она совсем не такая оптимистичная, как в этой статье, но на примере списания остатков заказов этого заметно не будет. Также в комментарии приведен рисунок - ментальная модель, используемая при синтезе запроса. Это два стоящих рядом столбика приходов и расходов, общие отрезки в которых и образуют результат. Двумерная модель транспортной задачи, приведенная в данной статье, очевидно, нагляднее.
2) - также говорится об использовании аналогии между списанием по партиям и транспортной задачей, правда для скорости она решается не запросом, а программно. Обратите внимание на скриншоты хода решения задачи - они очень похожи на рисунки из статьи.
Ну и остались вопросы по постановке задачи. Что-то из серии "угадал все буквы, но не смог назвать слова" (это я про себя). Понятно, когда есть несколько заказов и требуется закрыть их одним поступлением. Тогда закрываем их по ФИФО. Например, заполняем товары и количество, затем запускаем обработку заполнения табличной части и она разбивает строки по заказам. То есть запрос в ОЗТЧ? Но почему не свернуть ТЧ по одинаковым товарам перед вызовом ОЗТЧ. Это ведь сам подбор делает (серии?). Как кладовщик решает, что заказа нет? В этом случае оформляет ордер? В какой момент на ордер поступление делается? То есть непонятна роль ордера и причины возникновения строк с одинаковым товаром. Или обработка одним запросом сразу много поступлений обрабатывает? - Разъясните, пожалуйста!
(1), спасибо за отзыв.
Интересные ссылки! Жаль, что они мне не попались в процессе работы над задачей.
В первой статье, действительно, интересное решение и его проще осознать. Я бы добавил туда несколько иллюстраций.
Над оценкой трудоемкости запроса я задумался. Мой перебор далеко не оптимален, у него трудоемкость О(n * m). Да и запросы на стороне SQL, как я понимаю, приводят к полному соединению таблиц, и только потом применению условия (я клоню к тому, что трудоемкость не должна делиться на два n * m/ 2) . Пусть даже так, но почему тогда запрос отрабатывает быстрее? На досуге я над этим поработаю.
Мне показалась, что здесь есть над чем подумать. Например, что будет, если я выберу сначала только интервалы из двух таблиц, отсортирую и соединю их с двумя другими таблицами по условию попадания в интервал? Не получится ли сразу искомая таблица?
По поводу постановки задачи. В статье я немного упростил ее. Возможно, в этом причина вопросов.
Начну с кладовщика. У него свой АРМ. В нем он просто сканирует штрихкод товара и переносит его в табличную часть. По нажатию кнопки "Принять" АРМ делает за него всю работу: анализирует остатки по Заказам поставщику, по Поступлениям товаров и услуг и создает соответствующие документы. Если поступления нет - перед нами излишек (Ордер на излишки), а если есть - обычный товар (Приходный ордер на товары). В целях сохранности товара кладовщик не знает какой документ был создан.
А теперь интересное. Нет никакой ОЗТЧ. Сам запрос в обработке проведения (о, ужас!). Подбор в поступление позволяет выбрать только товары из заказов, пусть, даже, нескольких. Таким образом, эти строки никогда не свернутся.
В момент проведения Поступления мы должны закрыть два взаимосвязанных регистра: +Товары к поступлению (какие товары предстоит принять на складе), -Излишки (какие товары из этого поступления уже находятся на складе). Если мы находим товар в излишках, значит, в Товары к поступлению мы его не пишем.
Надеюсь, я не слишком выболтал бизнес-процессы фирмы, и Вам стало яснее.
Интересные ссылки! Жаль, что они мне не попались в процессе работы над задачей.
В первой статье, действительно, интересное решение и его проще осознать. Я бы добавил туда несколько иллюстраций.
Над оценкой трудоемкости запроса я задумался. Мой перебор далеко не оптимален, у него трудоемкость О(n * m). Да и запросы на стороне SQL, как я понимаю, приводят к полному соединению таблиц, и только потом применению условия (я клоню к тому, что трудоемкость не должна делиться на два n * m
Это два стоящих рядом столбика приходов и расходов, общие отрезки в которых и образуют результат.
Мне показалась, что здесь есть над чем подумать. Например, что будет, если я выберу сначала только интервалы из двух таблиц, отсортирую и соединю их с двумя другими таблицами по условию попадания в интервал? Не получится ли сразу искомая таблица?
По поводу постановки задачи. В статье я немного упростил ее. Возможно, в этом причина вопросов.
Начну с кладовщика. У него свой АРМ. В нем он просто сканирует штрихкод товара и переносит его в табличную часть. По нажатию кнопки "Принять" АРМ делает за него всю работу: анализирует остатки по Заказам поставщику, по Поступлениям товаров и услуг и создает соответствующие документы. Если поступления нет - перед нами излишек (Ордер на излишки), а если есть - обычный товар (Приходный ордер на товары). В целях сохранности товара кладовщик не знает какой документ был создан.
А теперь интересное. Нет никакой ОЗТЧ. Сам запрос в обработке проведения (о, ужас!). Подбор в поступление позволяет выбрать только товары из заказов, пусть, даже, нескольких. Таким образом, эти строки никогда не свернутся.
В момент проведения Поступления мы должны закрыть два взаимосвязанных регистра: +Товары к поступлению (какие товары предстоит принять на складе), -Излишки (какие товары из этого поступления уже находятся на складе). Если мы находим товар в излишках, значит, в Товары к поступлению мы его не пишем.
Надеюсь, я не слишком выболтал бизнес-процессы фирмы, и Вам стало яснее.
Это конечно все интересно. Но мне кажется, что в этом примере нет чистоты эксперимента, а именно:
1. Исходный массив данных. На примере рассматривается не большой массив данных тут и так понятно что прямой перебор справится быстрее SQl (SQL - это как межгалактический челнок, но его нужно разогнать). Было бы интересно посмотреть графики скорости с нарастанием объема обрабатываемых данных до сотен тысяч позицый.
2. Может я и ошибаюсь но в эксперименте данные обрабатываются из виртуальной таблицы значений(из кэша памяти), а не поднимаются с файловой системы. В этом случае прямому перебору данные предоставили прямо на блюдечке.
1. Исходный массив данных. На примере рассматривается не большой массив данных тут и так понятно что прямой перебор справится быстрее SQl (SQL - это как межгалактический челнок, но его нужно разогнать). Было бы интересно посмотреть графики скорости с нарастанием объема обрабатываемых данных до сотен тысяч позицый.
2. Может я и ошибаюсь но в эксперименте данные обрабатываются из виртуальной таблицы значений(из кэша памяти), а не поднимаются с файловой системы. В этом случае прямому перебору данные предоставили прямо на блюдечке.
(5), вы немного все переиначили.
- У меня получилось, что запрос отрабатывает быстрее, чем перебор, а не наоборот! В моем примере прямой перебор медленнее. Или вы ведете к тому, что преимущества запроса можно еще больше улучшить?
- Исходный массив данных. Об этом я обязательно должен был написать (и думал, что написал). Я не тестировал алгоритм на супер больших объемах. Например, таблица 1000 х 1000 у меня решалась несколько минут. Больше делать не стал.
- Здесь вы тоже не верно все истолковали. Для перебора используется таблицы объекта (внешней обработки). Непосредственно в них происходят вычисления. Для запроса же эти таблицы выгружаются в параметры запроса, при выполнении запроса помещаются во временные, и только потом используются для расчета нарастающего итога и дальнейших вычислений.
То есть, действий запросный метод выполняет больше.
Вот это я понимаю подход! Все с разъяснениями. Подобного рода задачи постоянно приходится решать, например, в ЗУПе когда НДФЛ нужно грамотно перекрыть и не держать остатков по периодам или перекрыть любой отрицательный остаток по регисту положительными остатками по этому же регистру. Но то что это Транспортная задача я даже не задумался.
Поставил + за изложение. Но вот за это :
"нередки ситуации, когда менеджер не успевает оформить Заказ поставщику и принимаемый товар записывается как излишек. Если с течением времени будет введен документ Поступление товаров и услуг по этому Заказу, то товар снимается с излишков и все - он уже на складе."
нужно бить линейкой по рукам того, кто придумал (организатора учета) . Сильно, больно и долго.
Это не уменьшает теоретической и методической ценности статьи.
"нередки ситуации, когда менеджер не успевает оформить Заказ поставщику и принимаемый товар записывается как излишек. Если с течением времени будет введен документ Поступление товаров и услуг по этому Заказу, то товар снимается с излишков и все - он уже на складе."
нужно бить линейкой по рукам того, кто придумал (организатора учета) . Сильно, больно и долго.
Это не уменьшает теоретической и методической ценности статьи.
Подскажите, пожалуйста, кто знает, как в примере с курсами валют реализовать на языке запросов следующее: "В третьей группе мы соединяем эти две таблицы по условию ПериодКурса, в результате чего получаем избыточное количество записей. Но достаточно сгруппировать их по дате документа и выбрать максимальное из значений ПериодКурса, как мы получим требуемую таблицу."
(17), спасибо. Из этой статьи я понял как объединить таблицу, содержащую все даты периода с колонкой дат известных остатков, а потом уже объединить с колонкой сумм известных остатков.
у Вас же присоединяются сразу две колонки и я не представляю, что потом с этой таблицей делать, чтобы выделить из нее нужное
у Вас же присоединяются сразу две колонки и я не представляю, что потом с этой таблицей делать, чтобы выделить из нее нужное
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
Открыть