|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Изерлонер (схема данных на первой картинке) На второй моей картинке конечно же. Там где две таблицы tblNodeElement и tblZehNorm. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 18:17 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
ИзерлонерПрограммист-ЛюбительНазначение системы - вести учет ремонта изделий. Нет. Непосредственно учет ведется в бухгалтерии на их базе. Таблицы которой и использую. О том много уже писал, то к чему пришел сейчас с учетом - устраивает. Учет - не моя задача. Я только импортирую их данные и обрабатываю их. Моя задача что бы все что там у бухгалтеров учитывается не выходило за рамки норм. Ну и соответственно подготовка отчетов по ремонту изделий, вот сколько и чего списали, а вот ссылка на позицию в нормативе. Все должно биться. Если не бьется - меня линчуют и вполне обоснованно. И все-таки твоя система ВЕДЕТ УЧЕТ ремонта изделий в тех разрезах, за которые ты отвечаешь. ИзерлонерПрограммист-ЛюбительПри ремонте изделия ремонту могут подвергаться любые его элементы (составные части). Ремонт может вестись в разных цехах. Один и тот же элемент изделия может ремонтироваться в разных (более чем одном цехе). Так. Правда изделий одновременно ремонтируемых в разных цехах не так уж много, основная масса - одно изделие (сборка, агрегат) - один цех. Это и спасало, так как при таких условиях моя система выдает корректные данные. Но есть некоторые изделия и запчасти к ним которые проходят не по одному цеху. Ну например какие-то крепежные изделия, перемычки металлизации, которые списываются не на какую-то сборку, а на все большое изделие (вертолет) в целом, а соответственно проходят практически по всем цехам. Вот по этим деталям проходит удвоение, утроение и т.д. с чем и пытаюсь бороться, так как корректировать полученные данные на выходе как правило нет времени, и в нормативе по этим деталям получается чушь собачья. Хорошо что пока никто не обратил внимания. Это отмазки для бедных. Если у тебя де-факто связь сущностей М:М а ты звложил 1:М - ну молодец, сам себе злобный буратино. Такие ошибки НЕ ДОЛЖНЫ быть допущены. Как только это все-таки обнаружено, надо СРАЗУ ИМЕННО ЭТО исправлять. Любым потом и кровью. Это грубейшая ошибка, которую я никак не могу принять. ИзерлонерПрограммист-ЛюбительВ каждом цехе существуют свои нормы расхода при ремонте элементов изделия. Во время ремонта происходит фактическое выписывание (выделение) элементов для ремонта. Общее количество всех элементов, выписанных за время ремонта изделия, суммируется и сравнивается с нормами расхода, чтобы контролировать экономию или перерасход в разрезе цехов и всего по изделию. Совершенно точно. ..сравнивается с нормами расхода, и вообще с количеством сколько вообще таких деталей стоит на изделии. Превышение норм расхода еще не критично (если это не массовое явление) и можно объяснить, а вот превышение количества на изделия чревато проблемами при защите цены. Как может быть выписано на ремонт изделия А шесть штук подшипников типа... если их там всего два? Для этого у меня в системе есть индикация (условное форматирование) - превысило норму - ячейка окрашивается в оранжевый цвет, я как нормировщик принимаю решение пропустить или нет, могу вызвать из цеха ответственных "Ходи сюда - почему выписали больше? Если надо - пиши рапорт, что так надо и почему надо". Превышено количество на изделии (самом изделии как таковом, сборке, агрегате) - красный цвет. Тут же такое "требование" (документ на списание) отклоняю. Частенько происходит. А учитывая то что по некоторым деталям у меня идет удвоение, утроение, возникают мои ошибки. Удвоение и утроения БЫТЬ НЕ ДОЛЖНО. Если оно проявилось, СРАЗУ ИСПРАВЛЯТЬ. ИзерлонерПрограммист-ЛюбительВозвращаясь к более узкому вопросу - правильно я понимаю, что проблему вызывает запрос, подсчитывающий общее количество фактически израсходованных элементов и общие нормы в разрезе цехов/всего по изделию ? Общее количество по выписанных по факту расчитывается сейчас корректно. Есть мелкие ошибки, по одной двум записям на изделие так же идет удвоение, пока не разобрался почему, ... так как эти ошибки достаточно легко обнаружить, ... не до них просто было и не заморачивался пока, просто держу в уме что такая проблема иногда возникает, при случае надо разобраться. Нормы тоже более менее, критичных ошибок вроде нет. А вот количество на изделии которое должно быть... врет система. И причину я вижу совершенно четко. (схема данных на первой картинке), а вот обойти ее... при такой схеме наверное возможно созданием отдельного рекурсивного запроса только по таблице tblNodeElement без включения tblZehNorm. И затем созданием общего запроса с включением в него этих данных... Мне кажется это сейчас единственный вариант. Если на количестве твоя система "врет", то это значит что это место у тебя ваапще НЕ СДЕЛАНО. Пачиму ?! По общему описанию в своем изложении, я, хоть убей, катастрофы или суперсложности не вижу. Ну, пробежаться по деревьям, посчитать листочки - делается от нуля ровно за 5 минут из которых 4 уходит на изучение примера из БОЛ. Посчитать с учетом твоих особенных цеховых норм - ну тут чуть подольше. Трудностей, при правильной организации схемы данных, я не вижу. Практических нюансов у тебя, конечно, до фига, но это нормальная работа - вникать в нюансы, дорабатывать схему БД, запросы и формы. К сожалению, опять получились общие советы. Конкретно я тебе ничего не подсказал. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 18:44 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Программист-ЛюбительЕсли у тебя де-факто связь сущностей М:М а ты звложил 1:М - ну молодец, сам себе злобный буратино. Э-э-э.. если имеется ввиду связь цех - запчасть, то связь таки М:М. tblContractor - таблица с цехами (а так же с поставщиками, покупателями и т.д. контрагентами - все в одной таблице). ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 19:26 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
понятное дело поставщики и др. в нормативах не участвуют. Задается соответственно в таблице tblZehNorm соответствующим внешним ключем. Ключей поставщиков там понятно - нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 19:29 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Я имел в виду процесс ремонта элемента в нескольких цехах. Ты писал что у тебя это невозможно ? На схеме данных надо делать подписи к таблицам. Одно-два-три предложения, как можно более конкретно описывающие назначение таблицы. Часто я делаю дополнительные комментарии просто на свободном пространстве схемы данных. Привожу содержание важных справочников (шрифтом постоянной ширины). Твоя схема недостаточно хорошо читается. Покажи код заполнения дерева. Если у тебя всякий раз открываются рекордсеты для каждого нового уровня, то это время можно в разы сократить - за счет филтьрации одинажды открытого "широкого" рекордсета или за счет шейпов. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 19:38 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Когда я делал (вернее переделывал из твоего примера) код для заполнения TreeView я про рекордсеты весьма мало знал, можно сказать вообще ничего. Так что ... вот: Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139.
Выглядит не очень, и недостатков масса. Но так как функционально я форму с тривью нигде не использую, разве что посмотреть/проверить входимость изделий - пока ничего не переделывал. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 19:50 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Программист-ЛюбительЯ имел в виду процесс ремонта элемента в нескольких цехах. Ты писал что у тебя это невозможно ? Возможно. Но так как данные о количестве деталей в изделии, и нормы расхода разнесены по разным таблицам, а рекурсивный запрос строится на объединении этих (и нескольких других) таблиц, идет кратное увеличение количества на изделие. ... в общем я все-таки прихожу к выводу что схема в принципе верная. Не верно было делать рекурсивный запрос по соединению этих таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 19:57 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Заполненное дерево. ...На домашнем компе выводилось минут пять. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 20:01 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Программист-ЛюбительНа схеме данных надо делать подписи к таблицам. по правой кнопке мыши - "создать примечание"? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 20:06 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
По примечаниям да. По дереву. Для дерева должно быть достаточно двух таблиц, хранящих структуру изделий. Лишнего в запросе быть не должно. Обязано строиться моментом. Для ускорения открой рекордсет со всеми записями и потом для загрузки очередного уровня применяй к нему фильтр "iReplaseableElementID_Parent=" & iElementID. Переменную рекордсета сделай глобальной или передавай как параметр при рекурсивном обходе. Должно в разы ускориться. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 21:58 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Программист-Любитель, кстати, по поводу глобальной переменной рекордсета. В одном из твоих примеров обратил внимание что в процедуре ты открываешь рекордсет присваиааешь ему значение (ссылку на таблицу)... а где закрытие рекордсета? Там не полный код был, только одной процедуры. У себя я сделал закрытие на событие «закрытие формы» ... но не всегда действует. Иногда пытается закрыть рекордсет, который не был открыт. Как и открыть тоже не всегда получается. Ну или например при переходе в режим конструктора, тоже ошибки вылезают с открытием/закрытием рекордсета. Это всё мелочи, которые так или иначе быстро можно обойти при работе, поэтому сильно этим пока не заморачивался, как говорил – есть более насущные проблемы, мелочи оставляю на будущее (благо с базой работаю только я, ...никто другой пока и не сможет – столько косяков моментально вылезет, которые я знаю и знаю как работать что бы они не вылезали) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 10:49 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Ещё, по дереву вылезала ошибка при выводе одноименных агрегатов в разных изделиях, временно решил добавлением iNodeElementID в конец текста (в коде видно). Но это только временное решение, так как ID здесь мне нафинг не нужны. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 10:57 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Изерлонер временно решил добавлением iNodeElementID в конец текста (в коде видно) Код: vbnet 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 11:01 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Прошу прощения, вставилось не совсем корректно. Пишу со смартфона... При том эта ошибка характерна только для уровня агрегатов. Детали выводятся сколько угодно раз, хоть бы и назывались совершенно идентично. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 11:07 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
автортак как ID здесь мне нафинг не нужны. Я использую класс для генерации ключей: Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26.
Для каждого дерева - свой объект clsNodeKeyGenerator. Если на ключи совсем не наплевать, то в метод Create можно передавать параметры, на основании которых будет генерироваться ключ определённого вида. Можно также для каждого типа узла ввести свои счётчики (nodeKeyCounterType1, nodeKeyCounterType2 и т.д.), а тип узла передавать в качестве параметра в метод Create. Много вариантов. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 11:43 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
По поводу дубливания узлов в дереве. В случае, когда в тривью одни и те же объекты помещаются более одного раза, я добавляю в конец Key конктенацию nodes.Count В таге храню выражение <ИмяАйдиПоля>=<Значение>. Тем самым при анализе тага текущего узла всегда ясно, что это за сущность и какой у нее айди. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 12:24 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Программист-Любитель, можешь меня поздравить. Иногда полезно ощутить себя круглым дураком. Нафига я спрашивается городил рекурсивный запрос на объединении всех таблиц, создавая себе массу сложностей и проблем?! Все гораздо проще. Надо было сделать рекурсивный запрос на одной таблице tblNodeElement, как было сделано у тебя, а уже потом присобачивать туда все что хошь. Наименования элементов, единицы измерения, цеховые нормы и цеха и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 19:28 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Количество деталей в изделии считает теперь корректно. А общую норму запчастей (и материалов) на изделие можно получить простой группировкой на соединении рекурсивного запроса с таблицей tblZehNorm. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 19:31 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Программист-ЛюбительПо поводу дубливания узлов в дереве. В случае, когда в тривью одни и те же объекты помещаются более одного раза, я добавляю в конец Key конктенацию nodes.Count В таге храню выражение <ИмяАйдиПоля>=<Значение>. Тем самым при анализе тага текущего узла всегда ясно, что это за сущность и какой у нее айди. Если правильно помню - проблема возникла из-за введения в дерево разделов "Изделия, Материалы, ГСМ, Запчасти" у самих разделов получаются одинаковые ключи, хотя они и могу находится в разных агрегатах и изделиях, отсюда видимо и пошли сложности. Разберусь с этим чуть позже. ... Возможно в ведении этих разделов и нет смысла. Материалы и ГСМ можно и в других формах посмотреть, по дереву все равно с ними работать не удобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 19:38 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
На мой взгляд уровни Изделия, материалы, ГСМ, запчасти очень наглядно смотрятся. На форме, показывающей структуру узла должна быть какая-то визуальная группировка по тем же 4 разделам. Посмотри мой пример в сосоеднем топике про 64 битное дерево - я сделал новую форму frmIzdelieTreeAPI. Там есть програмная реализация некоторых приемов - динамическая загрузка субформ динамическое формирование источников данных форм открытие форм с позиционированием на нужную запись Эту форму и некоторые другие я в коде немного откомментировал. К сожадению, мои общеупотребительные модули, которые пришлось включить в проект мало откомментированы. Если не поленишься скачать и запуститьЮ можешь спрашивать на форуме, я отвечу на вопросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 19:53 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
ИзерлонерКоличество деталей в изделии считает теперь корректно. Дулю мне. Не все так замечательно Если деталь стоит в одной ветке дерева - например в сборке и в ее же подсборке, то суммирует. А вот если деталь стоит в совершенно разных агрегатах, но которые таки стоят все в одном изделии, расчитывает количество деталей на агрегат, вместо того что бы выдать общую сумму на изделие. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 20:04 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
ИзерлонерЕсли деталь стоит в одной ветке дерева - например в сборке и в ее же подсборке, то суммирует. И даже не так. Суммирует если агрегата два (и более), вот для них выводит корректно. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 20:06 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
После подсчета по дереву изделия надо еще раз просуммировать по рутовскому айди и аиди запчасти. Вот и будет сколько всего таких деталей в этом изделии. Все остальный узлы дерева - неважно. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 20:07 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Код: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 20:07 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Программист-ЛюбительПосле подсчета по дереву изделия надо еще раз просуммировать по рутовскому айди и аиди запчасти. Вот и будет сколько всего таких деталей в этом изделии. Т.е. тоже группировка? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 20:09 |
|
|
start [/forum/topic.php?fid=45&msg=38247370&tid=1619858]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
154ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 312ms |
total: | 556ms |
0 / 0 |