• Откуда: Самара
  • На форуме с 4 апреля 2011
  • Сообщений: 209

Тема: Маршрут изготовления детали в отчете. Проблема множественных JOIN

Добрый день, коллеги!
Помогите советом, если у кого есть опыт решения подобных задач.
Необходимо сделать отчет который бы включал в себя информацию:
Уровень входимости (1.1, 1.2...), наименование детали (узнал), его обозначение, сортамент материала, сам материал, кол-во деталей, масса заготовки, размер заготовки и самое интересное - необходимо расписать маршрут изготовления детали - т.е. участок и операции и время их выполнения. Ну и промежуточные суммы по каждой операции по всем деталям (сумма сверху вниз), и сумма по всем операциям по одной детали (сумма по горизонтали).
Пример отчета для наглядности приложен.
В чем собственно вопрос -
Первую часть данных (до операций) скомпоновать и вывести в отчет не представляет труда, но вот с операциями беда.
Нужно чтобы кол-во столбцов операций было одинаково у всех деталей, т.к. нужно подводить суммы, и применять в дальнейшем фильтры, поэтому отчет будет представлять из себя длинную горизонтальную таблицу в которой мы будем подключать каждую операцию путем переджойнивания с деталью, и вывода времени выполнения, для получения которой количество JOIN в запросе будет просто зашкаливать (т.к. операций много ), что приведет к тому что даже на небольших изделиях мы получим коллапс.

Как выйти из положения? Есть какие то варианты?

Post's attachments

Template_27112015 183830.xls 36 Кб, 4 скачиваний с 2015-12-02 

You don't have the permssions to download the attachments of this post.

  • Откуда: Новосибирск
  • На форуме с 30 сентября 2003
  • Сообщений: 4,310

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

на новом репортере на мой взгляд лучше всего сделать так:

  • Заводим именованное значение GetTpData( OperNum, CehaNum )

  • В каждой ячейке передаем параметр ( номер операции, номер цеха)

  • Для суммирования по вертикали заводим счетчики

В репортере

  • Определяем на старте какие цеха участвуют, строим их порядок (если это заранее неизвестно) (

  • В именованном значении при смене строки, открываем набора данных. По переданным номерам рассчитываем значения и отдаем в ячейку.

В старом аналогично можно наверное, но там вариаций больше.

Вопрос в этом был?

С бланком сложнее, в нем надо сразу предусмотреть максимальное число операций и цехов.

Можно еще данные как-то подготовить заранее специальным образом (промежуточная таблица рассчитываемая на старте). Но тут вариантов может быть много. Предлагаемый первым наверное самый  простой в реализации.

  • Откуда: Самара
  • На форуме с 4 апреля 2011
  • Сообщений: 209

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

Олег Зырянов пишет:

на новом репортере на мой взгляд лучше всего сделать так...

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

Олег Зырянов пишет:

С бланком сложнее, в нем надо сразу предусмотреть максимальное число операций и цехов.

Это можно, есть полный список цехов и операций выполняемых в них. Но проблема в том что мы не можем решить эту задачу стандартным подходом, т.к. в источнике данных будет слишком много LEFT JOIN и процесс выгрузки просто повиснет на деталях даже с составом до  100 позиций, не говоря уже о реальных сборках в составе которых по 1500 деталей.

  • Откуда: Новосибирск
  • На форуме с 30 сентября 2003
  • Сообщений: 4,310

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

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

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

Цена нового репортера небольшая, лицензии плавающие так что их не надо сразу покупать кучей на все места. Зато разработка новых отчетов и бланков будет идти проще и быстрее. Плюс офис можно без Ms Access, поддержка новых офисов ну над развитием работаем.

  • Откуда: Самара
  • На форуме с 4 апреля 2011
  • Сообщений: 209

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

В итоге что посоветуете? Делать в источнике данных более 100 Left Join ? Тогда при изделии из 1500 деталей будет выгружаться более 150 000 записей... Как бы это не затянулось на сутки...

  • Откуда: Новосибирск
  • На форуме с 30 сентября 2003
  • Сообщений: 4,310

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

150 000 записе

Это не большое количество скажем честно.  Можно заменить на 100 * 1500 подзапросов - но это похуже будет пожалуй.
А вот 100 Join может просадку дасть в таких количествах, но больше стоит опасаться что не будет ли каких ограничений

Если кол-во пугает - просто рассчитайте колонки перед выполнением отчета. Тогда будет всего один join на таблицу с большим количеством полей.

Ответ от Антон Мороков (изменено: Антон Мороков, 4 декабря 2015 10:55:24)

  • Откуда: Самара
  • На форуме с 4 апреля 2011
  • Сообщений: 209

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

Олег Зырянов пишет:

Если кол-во пугает - просто рассчитайте колонки перед выполнением отчета. Тогда будет всего один join на таблицу с большим количеством полей.

Не совсем понял как это? У нас горизонтальный отчет и как его можно сделать одним JOIN ?
Когда мы выполним этот JOIN у нас в Аксессе будет нечто такое:
Деталь 1   Операция 1
Деталь 1   Операция 2
Деталь 1   Операция 3
и т.д.
Далее мы через опять же JOIN запросим время из атрибутов.

Как потом распределить это все в горизонталь?

Также необходимо понимать что не все операции есть у всех деталей. Т.е. если мы рассчитали кол-во колонок сразу, то какие то из них будут пустые (пропущены). Это устраивает. Но репортер так не строит. По крайней мере в горизонталь.

  • Откуда: Новосибирск
  • На форуме с 30 сентября 2003
  • Сообщений: 4,310

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

алее мы через опять же JOIN запросим время из атрибутов.

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

Реализуем в Implement подготовку нашей таблицы (делаем расчет). Потом ее одну делаем Join (ну либо как придумаем, там вариаций много).

  • Откуда: Самара
  • На форуме с 4 апреля 2011
  • Сообщений: 209

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

Олег Зырянов пишет:

алее мы через опять же JOIN запросим время из атрибутов.

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

Реализуем в Implement подготовку нашей таблицы (делаем расчет). Потом ее одну делаем Join (ну либо как придумаем, там вариаций много).

Видимо я не в теме, о чем тут говорится. Как это делается? Можно по шагам...

  • Откуда: Новосибирск
  • На форуме с 30 сентября 2003
  • Сообщений: 4,310

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

Видимо я не в теме, о чем тут говорится. Как это делается? Можно по шагам...

ну это не столько отчет сколько программирование на Access.

В новом репортере мы как раз и избавляем как можем от этого.

Ответ от Антон Мороков (изменено: Антон Мороков, 6 декабря 2015 21:46:57)

  • Откуда: Самара
  • На форуме с 4 апреля 2011
  • Сообщений: 209

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

Олег Зырянов пишет:

Видимо я не в теме, о чем тут говорится. Как это делается? Можно по шагам...

ну это не столько отчет сколько программирование на Access.

В новом репортере мы как раз и избавляем как можем от этого.

Что то понятно, что то нет.
Давайте подытожим  тему.
Можно ли НЕ будучи программистом, а человеком просто знакомым с принципами построения отчетов в Технолоджикс 6, стандартными методами решить вышеупомянутую задачу, не попав в неприятности с многократным JOIN выражающиеся в повисании системы на долгое время?
Если возможно уйти от 100 шт. JOIN стандартными методами - то как?
Если нельзя - то какие самые доступные (простые) варианты?

  • Откуда: Новосибирск
  • На форуме с 30 сентября 2003
  • Сообщений: 4,310

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

Можно ли НЕ будучи программистом, а человеком просто знакомым с принципами построения отчетов в Технолоджикс 6

Можно конечно, и способов много.
Что в старом, что в новом репортере вы так или иначе пишете мини-программу. Просто в старом вся работа перекладывалась на приложения офиса (требуется знание офиса), а в новом на TCS (здесь возможности развиваем мы сами).

Если возможно уйти от 100 шт. JOIN стандартными методами - то как?

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

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

Ответ от Антон Мороков (изменено: Антон Мороков, 8 декабря 2015 16:46:51)

  • Откуда: Самара
  • На форуме с 4 апреля 2011
  • Сообщений: 209

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

Сегодня весь день провел за этим отчетом, но ничего вразумительного получить не смог. Пробовал и подзапросы и обычные JOIN.
Подскажите кто понимает в этом как вывести время операции в столбец с операцией. При этом не попортив все что есть уже.

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


Количество и наименование операций известно и можно прописать их по горизонтали, а время проставлять только у тех которые применяются в ТП на конкретную деталь


Идея вытаскивания операции вернее времени ее - такова -   У каждой операции присвоен код операции, и в запросе мы проверяем если код операции равен 1 , но вытаскиваем время и пишем в первый столбец, далее операция с кодом два если нашли пишем в столбец 2 и т.д .

На словах вроде просто, а запрос такой смонстрячить дело оказалось не тривиальное.

Post's attachments

ReportDB_08122015 172554.zip 56.11 Кб, 5 скачиваний с 2015-12-08 

You don't have the permssions to download the attachments of this post.

  • Откуда: Самара
  • На форуме с 4 апреля 2011
  • Сообщений: 209

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

Позже опубликую свой запрос с пояснениями чтобы было проще разбираться.

Ответ от Антон Мороков (изменено: , 9 декабря 2015 11:03:34)

  • Откуда: Самара
  • На форуме с 4 апреля 2011
  • Сообщений: 209

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

SELECT
R.P9 as vhod, R.P21 as obozn, R.P22 as naim, R.P27 as tip, PosTP.P5 as material, R.P10 as kolich, ParPosTP.P7 as Massa, PPTP.P7 as Razmer

FROM

(((RptSheet AS R

LEFT JOIN

TP ON (R.P2=TP.P1 and R.P27<>'ДОК'))

LEFT JOIN

PosTP ON (TP.P2=PosTP.P1 and TP.P12='М'))

LEFT JOIN

ParPosTP ON (TP.P2=ParPosTP.P1 and ParPosTP.P14='TCS_ST_KG'))

LEFT JOIN

ParPosTP as PPTP ON (TP.P2=PPTP.P1 and PPTP.P14='TCS_MZ_RZ')

GROUP BY R.P9, R.P21, R.P22, R.P27, PosTP.P5, R.P10, ParPosTP.P7, PPTP.P7

R -RptSheet
TP - техпроцесс
PosTP - номенклатурная позиция
ParPosTP - параметры позиции ТП

Результат выполнения запроса приложен:

Post's attachments

Template_09122015 115905.xls 37 Кб, 4 скачиваний с 2015-12-09 

You don't have the permssions to download the attachments of this post.

  • Откуда: Самара
  • На форуме с 4 апреля 2011
  • Сообщений: 209

Re: Маршрут изготовления детали в отчете. Проблема множественных JOIN

Отчет который бы хотелось видеть

Post's attachments

Template_09122015 115906.xls 28 Кб, 6 скачиваний с 2015-12-09 

You don't have the permssions to download the attachments of this post.