|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Помогите пожалуйста с решением задачи. Имеем таблицы tblElement и tblNodeElement см. на схеме ниже. (схема взята из примера приведенного Программистом-Любителем, т.к. немного попроще чем подобная схема в моей базе. Необходимо вывести суммарную норму расхода запчастей (при ремонте) и суммарное их количество в (корневом) изделии. Расчет нормы расхода и количества в изделии, как мне кажется, производится по следующим алгоритмам: Норма расхода запчасти на изделие: Низд = ((([НсбN] *[ КсбN])*[KсбN-1]+[НсбN-1]*[КсбN-1])*[KсбN-2]+ [НсбN-2]*[КсбN-2])….. Количество запчастей в (корневом) изделии: KЗизд =( ([KЗсбN]*[KсбN-1]+[КЗсбN-1])*[КсбN-2]+[КЗсбN-2])*КсбN-3+…… Где Низд – норма расхода запчасти на изделие КЗизд – суммарное количество запчасти в изделии Ксб – количество сборок N – количество уровней вложенности (изделие-сборка-подсборка-подподсборка…) И соответственно НсбN, КЗсбN, KсбN – норма, количество запчастей, количество подсборок самого нижнего уровня [НсбN-1], [КЗсбN-1], [КсбN-1] –норма, количество запчастей, количество подсборок на уровень выше. На выходе должна получиться таблица с полями iElementID_Root, iElementID, decNorm, decCnt где для каждой запчасти корневого изделия должна быть указана (суммарная) норма расхода на ремонт, и общее количество запчастей на изделие. Изначально вся схема сделана в MS_SQL Server, но так как вся работа с базой идет через Access (ADP проект Access 2003 + MS_SQL Server 2008 R2), то пишу в этой ветке. Задача, по моему, сложная используется рекурсивный запрос (ниже приведу), на готовые решения не надеюсь, подскажите куда «бить головой» и хоть примерный ход решения. ...вообще описание сложное получилось, в жизни несколько попроще. Уровней вложенности у меня на текущий момент всего два и отчасти получалось решить эту задачку простой группировкой, не исключено впрочем увеличение количества уровней в будущем до максимум 5, поэтому привел "идеальный" алгоритм по которому их может быть сколько угодно. ... Правда как реализовать этот алгоритм через DML не представляю ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:05 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:06 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Я же уже давал в этом форуме пример запроса вычисляющего рекурсивно полное количество по всему дереву от корня до последних листиков ? Примеров рекурсивных запросов t-sql куча, приспособить под себя несложно. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:12 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#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.
... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:18 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Да П-Л все верно, очень хорошо что сразу на тебя "нарвался" просто не понимаю как приспособить этот рекурсивный запрос именно под вычисление норм и количеств. Само по себе то все это работает на ура, дерево строится, все что нужно выдает, а вот итоговые расчеты ... тут загвоздка ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:22 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#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.
Обратите внимание столбец nNodeElementCount считает количество листиков на ветке дерева перемножая предыдущие узлы iNodeElementIDiElementID_RootiElementID_ParentiElementIDsElementCodesElementNamesNodeElementAddressnNodeElementCount113131.140Ручка#13#12131331.123Колпачок#13#3#131313121.132Корпус#13#12#2413124 1.124Корпус-трубка#13#12#4#65131251.125Заглушка#13#12#5#8613126 1.126Конус#13#12#6#271312111.131Стержень#13#12#11#2813117 1.127Оболочка#13#12#11#7#691311101.130Пишущий механизм#13#12#11#10#810131081.128Шарик#13#12#11#10#8#811131091.129Обод#13#12#11#10#9#81414142.56868Изжелие2.56868 #14#017141417aaaaaaaaaa#14#17#018141418bbbbbbbbbb#14#18#0 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:24 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Я помню был вариант с адресами, по которым вроде как легко прослеживалась каждая деталь, где стоит и сколько их, но потом от адресов мы ушли. Все только через этот запрос. Сейчас об адресах вспоминать поздно, так как наработано уже весьма не мало. Плюс тут еще сложность что вычисляется не только количество деталей, но и их нормы расхода, а они вычисляются немного по другому алгоритму. В общем на выходе получается "швах". Я делал расчет группировкой на основе данных полученных рекурсивным запросом. Возникли проблемы при некоторых условиях. ... Блин. Не хочу еще усложнять, если эти условия описывать это довольно много добавить надо к исходному посту. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:28 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Во-во. Про эти адреса и писал :( У меня их нет. Надо прочитать, подумать. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:30 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Чую, надо шаманить с этим: Код: sql 1.
Спасибо П-Л! ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:42 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Вот я добавил поле норма расхода и посчитал его для каждого листика дерева. Т.е. для каждого листика берется его путь наверх, в каждом узле сколько-то веток, это число умножается на норму расхода для данной ветки. dbNodeElementNorma10000824548181633625614081024 Формула абсолютно тривиальная, точно такая же как и рсачет количества. Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:47 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
1 0 0 0 0,8 2 4,5 4,8 1,8 1,6 3,36 2,56 1,408 1,024 Запятые плохо встали. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:48 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Суть понятна, попробую реализовать это в моем "кривом" коде. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:56 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Ага. Перемножайте на каждом узле кол-во штук на норму расхода. Должно быть несложно. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 21:58 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Изерлонер...попробую реализовать это в моем "кривом" коде. вот правда, код кривой до жути. Но если бы ты в свое время не направил, все было бы ишшо хуже. А кривости имеют вполне объективные причины, жуткая загрузка текущей работой (при этом использую то что уже наработал с базой, что с одной стороны где-то ускоряет процесс, но при этом закрепляет текущее состояние базы, так как внести серьезное изменение пусть даже в кривую, но используемую в работе базу - чревато...) и отсутствие опыта. По тихоньку ситуация исправляется, надеюсь время у меня еще есть. Было бы обидно уйти с этого места работы так и не реализовав всего вложенного труда и того потенциала что дает эта база. ... Блин. За идею работаю! Не так страшно работу потерять и зарплату (другую найду) как все эти наработки. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2013, 22:05 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
П-Л, в общем где-то я перемудрил со схемой данных изначально. Не получается у меня. Подозреваю что из-за схемы. Ниже представлен кусок схемы данных. Проблема в том что данные о количестве деталей на изделие и нормы расхода разнесены по разным таблицам - выделил красным. Просто нету самой по себе нормы расхода на ремонт изделия (она есть как-бэ, и даже у меня в схеме отражена, но этот столбец фактически мной не используется, и вообще это не совсем верно, потому что норма на изделие зависит от частных норм по цехам, так что по идее это излишний столбец, данные в котором должны соответствовать сумме всех цеховых норм) Есть норма расхода запчастей на изделие В КОНКРЕТНОМ ЦЕХЕ и именно она важна. От нее плясать надо, именно этому служит таблица tblZehNorm. Твой код рекурсивного запроса я использую не на одной таблице (tblNodeElement), а на запросе включающем в себя фактически все таблицы схемы (из которых сейчас важны именно две представленные таблицы). Рекурсивный запрос позволяет строить иерархическую схему входимости изделий и в принципе корректно показывает все данные. Однако когда я пытаюсь получить итоговые данные - суммарные нормы, суммарное количество на изделие... Суммарное количество увеличивается кратно количеству цехов в которых ставится запчасть на это изделие. (оно и понятно, просто исходя из схемы данных). Т.е. запрос собирает все данные по запчасти на изделии, суммирует их корректно... а затем умножает в два, в три и т.д. (по количеству цехов) раза. С нормами дело обстоит несколько лучше. Я могу получить корректные данные по нормам сделав запрос на группировку по данным рекурсивного запроса, однако непосредственно в самом рекурсивном запросе вывести эти данные пока не получается, где-то безнадежно туплю, все время норма получается равной нулю (ну или единице исходя из Код: vbnet 1.
) В общем у меня два вопроса. Первое, как бы ты организовал учет (хотя учет здесь не совсем корректное слово, это скорее просто такой справочник нормативов, учет ведется в другом месте и не мной), если его необходимо вести по отдельным подразделениям (цехам) и в целом по изделию. Годится ли представленная ниже схема для этого? По мне так схема годится, просто исходя из того что она себя уже достаточно показала, и больших проблем не было, но сейчас после нескольких ударов головой ап стену, у меня сомнения возникли Второе, если твой вариант прилично отличается от представленного, то что вообще возможно сделать что бы поправить ситуацию и при этом не пришлось все переделывать с нуля? Рано или поздно все равно видимо придется, когда приобрету достаточно опыта и буду совершенно четко понимать что и как должно быть, и что вообще нужно ... |
|||
:
Нравится:
Не нравится:
|
|||
02.05.2013, 19:18 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
ЗЫ: слово Replaseable вычеркнул нафинг, что бы не путало. По факту использования нету там никакого Replaseable, я эту возможность внес в схему данных (при том здорово ее усложнив), но пока она остается "мертвой" и не используется. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.05.2013, 19:21 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Изерлонер что вообще возможно сделать что бы поправить ситуацию и при этом не пришлось все переделывать с нуля? Если не трогать схему, то я пока как вариант вижу создание отдельных "хитрых" запросов, на основе результатов рекурсивного, отдельно выводящих данные по количеству запчастей в изделии, по нормам (это по сути уже есть, только чуть доработать), и наконец общего запроса объединяющего все эти отдельные данные. Минус - по моему горькому опыту работает подобный подход весьма медленно. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.05.2013, 19:32 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
ЗЫ2: пусть тебя не смущают поля strPodrasdel.. iPodrasdel.. и иже с ними. Схема так или иначе постоянно улучшается дорабатывается, а хвосты остаются, либо по причине того что на них были сделаны запросы и они пока не исправлены, либо тупо по нехватке времени и опасения поломать что хоть криво, но работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.05.2013, 19:41 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Изерлонери вообще это не совсем верно, потому что норма на изделие зависит от частных норм по цехам ЗЫ_3: я часто путаю что от чего зависит, потому что на практике и в теории разные подходы. В литературе (руководства по ремонту, альбомы и перечни) естественно нету никаких цехов. Норма всегда дается на ремонт изделия. Однако на практике каждому цеху на ремонт изделия назначается своя норма, в сумме это все конечно должно соответствовать. Так что очень не просто взять и выкинуть какие-то столбцы. Впрочем к сожалению нормы в литературе даются далеко не на весь перечень запчастей и материалов, на большую часть это все устанавливается исходя из практики ремонта пальцем в потолок и статистики. Для норм имеющих основание в ремонтной документации введен столбец decNodeElementNormObosn и столбцы strObosnovanie и strDopObosnovanie в которых прописывается ссылка на документ. Опять же на деле пока это все только задел на будущее, и не имеет сейчас критического значения. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.05.2013, 20:07 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
У тебя задача достаточно объемная, надо опять начинать от печки. Я, честно, уже подзабыл - ты как-то раньше давал более-менее подробные объяснения про свою систему. То, что у тебя некая каша из цехов/ремонтов, у меня осталось четкое впечатление. Сказать какие конкретно таблицы и как именно надо реорганизовать, увы, не смогу - надо снова погрузиться в твою задачку. Может ты бы где-то типа в гугль докс завел описание бизнес-требований и функциональных требований, чтобы к ним можно было обращаться и совместно редактировать, а ? Я бы с радостью помог, но исходной информации маловато. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.05.2013, 22:23 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Написать можно, только по опыту предыдущих попыток, я боюсь завязнуть в не существенных мелочах, а так же в своих хотелках. Всё не так уж и сложно, но человеку со стороны трудно вникнуть, отсюда попытки объяснить простые вещи своими словами что только увеличивает сложность описания. По моему мнению система не столь сложна, проблема с ее реализацией не опытным разработчиком (мной). Что касается хотелок... Есть конечно и сложности, на которые я просто закрываю глаза. Какие то дикие требования что в одном случае нормы рассчитываются так, в другом иначе, в одном случае деталь подлежит обязательной замене, в другом заменяется только по дефектации... В этом всём в жизни то разобраться не получается, не то что реализовать это в базе. ...когда я обратился к главному инженеру с предложением автоматизировать всё это, дабы упорядочить весь этот бардак – его ответ был – если автоматизировать бардак, то получится автоматизированный бардак. После нескольких попыток просто разобраться, стал тупо игнорировать все эти сложности, они все равно погоды не делают, и на 80–90% можно закрыть все потребности упрощенной системой, которую и пытаюсь реализовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 07:14 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
А оставшиеся 10–20% можно привести к нужному виду, либо на худой конец доработать ручками. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 07:19 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
П–Л, я ещё боюсь что не так уж много времени мне осталось. На полноценную переработку схемы его нет. На днях мне капитально влетело от начальства с тем что не успел в срок сделать отчёт по ремонту, с лишением премии и всё такое. Правда полноценные исходные данные для этого отчета я получил лишь накануне, и сделать всё в срок возможно было бы если бы моя система в автоматически режиме готовила бы отчёт со всем оформлением и сбрасывала его в эксель уже оформленным, для дальнейшей проверки и распечатки. Пока я такого не реализовал. Начальству же глубоко до лампочки что даже то что я сделал позволяет ускорить работу в разы, и сидела бы на моем месте тетя со средним образованием и эксель необходимого отчета они недели две дожидались бы. «что там делать?! Разработал нормы расхода и контролируй» «Ты! Как нормировщик обязан копировать и собирать все счёт фактуры на защиту, это не работа экономистов» А ещё я обязан разрабатывать нормы расхода материалов и запчастей для всего производства в целом и отдельных подразделений (цехов), на других предприятиях для такого работают целые отделы вообще то. А ещё составлять планы развития производства и отслеживать их выполнение. А ещё подменять отсутствующих технологов по цехам, так как народ не держится и уходит, и кому то надо и эту работу вести. (конечно не я один на замене, но нас мало). И еще много много других ещё. Если при следующем отчете ситуация с задержкой отчета повториться (а так оно и будет! Иначе и быть не может, до тех пор как я запущу систему в полноценное использование) меня скорей всего уволят. Как уже писал, жалко не столько рабочего места, сколько вложенного труда, и того потенциала который так и останется не реализованным. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 07:52 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Ну в принципе опять та же ситуация: четкого описания проблемы нет, четкой постановки задачи тоже, как я понял из текущих реплиу чего-то надо посчитать. Отсюда и советы будет неконкретные. На количестве записей несколько десятков тысяч записей все подобные расчетв должны летать. Если не летает - увы, виноват радиус кривизны собственных рук. На том числе сущностей, что у тебя есть при нормально организованных индексах и запросах все эти нормы должны считаться ОЧЕНЬ быстро. Из твоего бессистемного изложения у меня отложилось следующее. Структура изделия по элементвм (вниз по сборкам, подсборкам до самых мелких деталей) вопросов не вызывает. Все остальное - вызывает. Назначение системы - вести учет ремонта изделий. При ремонте изделия ремонту могут подвергаться любые его элементы (составные части). Ремонт может вестись в разных цехах. Один и тот же элемент изделия может ремонтироваться в разных (более чем одном цехе). В каждом цехе существуют свои нормы расхода при ремонте элементов изделия. Во время ремонта происходит фактическое выписывание (выделение) элементов для ремонта. Общее количество всех элементов, выписанных за время ремонта изделия, суммируется и сравнивается с нормами расхода, чтобы контролировать экономию или перерасход в разрезе цехов и всего по изделию. В такой постановке задача не кажется сложной. Я бы гарантировал готовый результат под ключ за 1 человеко-месяц (с хорошими, удобными формами и отчетами), при условии использования своей собственной платформы. Возвращаясь к более узкому вопросу - правильно я понимаю, что проблему вызывает запрос, подсчитывающий общее количество фактически израсходованных элементов и общие нормы в разрезе цехов/всего по изделию ? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 12:27 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Программист-ЛюбительНа количестве записей несколько десятков тысяч записей все подобные расчетв должны летать. Если не летает - увы, виноват радиус кривизны собственных рук. На том числе сущностей, что у тебя есть при нормально организованных индексах и запросах все эти нормы должны считаться ОЧЕНЬ быстро. Здесь ситуация несколько исправилась. Не скажу что все прямо так летает, но в сравнении с тем что было раньше... да летает. По крайней мере есть несколько форм с отвязанным рекордсетом в которых при перемещении по записям ... скажем так в мастер форме, в подчиненной меняется рекордсорс по соответствующему запросу и высвечивается результат в доли ... ну максимум в секунду. Это вполне устраивает... Ну есть проблема с выводом иерархии в тривью, там расчет длится 30-60 секунд, просто так все организовал что расчитываются и выводятся все имеющиеся изделия, но форма с тривью мной используется очень редко, потому пока не заморачиваюсь. Там просто переделать ее надо, но это пока не критично и особо ни на что не влияет, потому пока не занимался. Есть вещи важнее. Программист-ЛюбительНазначение системы - вести учет ремонта изделий. Нет. Непосредственно учет ведется в бухгалтерии на их базе. Таблицы которой и использую. О том много уже писал, то к чему пришел сейчас с учетом - устраивает. Учет - не моя задача. Я только импортирую их данные и обрабатываю их. Моя задача что бы все что там у бухгалтеров учитывается не выходило за рамки норм. Ну и соответственно подготовка отчетов по ремонту изделий, вот сколько и чего списали, а вот ссылка на позицию в нормативе. Все должно биться. Если не бьется - меня линчуют и вполне обоснованно. Программист-ЛюбительПри ремонте изделия ремонту могут подвергаться любые его элементы (составные части). Ремонт может вестись в разных цехах. Один и тот же элемент изделия может ремонтироваться в разных (более чем одном цехе). Так. Правда изделий одновременно ремонтируемых в разных цехах не так уж много, основная масса - одно изделие (сборка, агрегат) - один цех. Это и спасало, так как при таких условиях моя система выдает корректные данные. Но есть некоторые изделия и запчасти к ним которые проходят не по одному цеху. Ну например какие-то крепежные изделия, перемычки металлизации, которые списываются не на какую-то сборку, а на все большое изделие (вертолет) в целом, а соответственно проходят практически по всем цехам. Вот по этим деталям проходит удвоение, утроение и т.д. с чем и пытаюсь бороться, так как корректировать полученные данные на выходе как правило нет времени, и в нормативе по этим деталям получается чушь собачья. Хорошо что пока никто не обратил внимания. Программист-ЛюбительВ каждом цехе существуют свои нормы расхода при ремонте элементов изделия. Во время ремонта происходит фактическое выписывание (выделение) элементов для ремонта. Общее количество всех элементов, выписанных за время ремонта изделия, суммируется и сравнивается с нормами расхода, чтобы контролировать экономию или перерасход в разрезе цехов и всего по изделию. Совершенно точно. ..сравнивается с нормами расхода, и вообще с количеством сколько вообще таких деталей стоит на изделии. Превышение норм расхода еще не критично (если это не массовое явление) и можно объяснить, а вот превышение количества на изделия чревато проблемами при защите цены. Как может быть выписано на ремонт изделия А шесть штук подшипников типа... если их там всего два? Для этого у меня в системе есть индикация (условное форматирование) - превысило норму - ячейка окрашивается в оранжевый цвет, я как нормировщик принимаю решение пропустить или нет, могу вызвать из цеха ответственных "Ходи сюда - почему выписали больше? Если надо - пиши рапорт, что так надо и почему надо". Превышено количество на изделии (самом изделии как таковом, сборке, агрегате) - красный цвет. Тут же такое "требование" (документ на списание) отклоняю. Частенько происходит. А учитывая то что по некоторым деталям у меня идет удвоение, утроение, возникают мои ошибки. Программист-ЛюбительВозвращаясь к более узкому вопросу - правильно я понимаю, что проблему вызывает запрос, подсчитывающий общее количество фактически израсходованных элементов и общие нормы в разрезе цехов/всего по изделию ? Общее количество по выписанных по факту расчитывается сейчас корректно. Есть мелкие ошибки, по одной двум записям на изделие так же идет удвоение, пока не разобрался почему, ... так как эти ошибки достаточно легко обнаружить, ... не до них просто было и не заморачивался пока, просто держу в уме что такая проблема иногда возникает, при случае надо разобраться. Нормы тоже более менее, критичных ошибок вроде нет. А вот количество на изделии которое должно быть... врет система. И причину я вижу совершенно четко. (схема данных на первой картинке), а вот обойти ее... при такой схеме наверное возможно созданием отдельного рекурсивного запроса только по таблице tblNodeElement без включения tblZehNorm. И затем созданием общего запроса с включением в него этих данных... Мне кажется это сейчас единственный вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.05.2013, 18:14 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#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 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Оставляешь в запросе только айди рута (изделия в целом), айди запчасти, по полю расчитанного количества - агрегат суммы. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 20:15 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Программист-Любитель, не знаю и чего ты нам помогаешь, но без твоих советов и тем более примеров было бы ... очень плохо все. Весьма вероятно что давно бы оставил эту затею и грустно возился бы с экселем... до тех пор пока под зад бы не с работы не пнули, у нас это быстро. До меня нескольких человек сменили. Всё думают что один человек этакую прорву потянет. Не тянет значит работник плохой. А то что у работника соответствующих задаче инструментов нет ... то никак не дойдет. ... Военные блин (пусть и бывшие), особенная психология. Скачал твои примеры с соседней ветки, буду разбираться. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2013, 20:27 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
П-Л, думал сначала отдельную тему завести, но так-как вопрос все-таки не совсем по Акцесс, и более к тебе нежели к другим форумчанам - задаю его здесь. Я помню твои предупреждения о том что наименования таблиц и запросов должны звучать четко, да так что бы сразу было понятно о чем речь. Сейчас у меня проблема как раз в этой области. А конкретно по запросам. Если таблицы можно увидеть на схеме данных, посмотреть что от чего зависит, и тем более прописать в схеме примечания для каждой таблицы, то с запросами все сложнее. Для них нет такой схемы, к ним очень сложно придумать однозначные наименования (особенно если запросы по сути одни и те же и отличаются лишь в деталях) а возможно ли ставить для них примечания где-либо, я не знаю, и такой возможности не нашел. Между тем запросов у меня выше крыши (больше чем исходных таблиц). Не все из них нужные, какие-то заменены на более новые и проработанные, а старые остались либо для связи с кодом на VBA которые еще не успел поправить, либо еще для каких-то целей. Как бы то ни было имею массу запросов типа: Код: sql 1.
и т.д. и т.п. В результате даже самому стало сложно разобраться что это за запросы и какой же из них конкретно мне нужен. Ни примечаний, ничего поясняющего нет и как их туда всунуть не знаю, все кучей в окне студии слева. Хуже того из-за такого количества запросов порой долго не могу найти то что я непосредственно вчера-то делал. Как это все возможно организовать? И возможно ли где-то писать поясняющие примечания, что бы их видно было в окне студии. В конце концов возможно ли их отсортировать по дате создания, что бы хоть так прослеживалось что и когда было сделано, и соответственно вспомнить и понять для чего, с какой целью? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 11:24 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Есть разные мЕтоды 1. Использование полноценной студии с проектом типа базы данных 2. Использование серверной студии с хранением объектов (запросов, функций, процедур) в структуре "папок" сервера 3. Использование серверной студии с организацией файлов по функциональным блокам. У каждого свои плюсы и минусы. 1. + Самый методологически правильный, родной метод с точки зрения микрософта. + Можно пользоваться многими плюшками рефакторинга. + Контролируется правильность и непротиворечивость ВСЕХ объектов БД. + Можно девелопить на девелоперской и накатывать скрипты изменения на продакшен. - Нужна полная студия. - Нужно уметь работать с проектом типа базы данных. - Придется иметь отдельную модельную БД со скриптами генерации демоданных. - Нельзя рисовать таблицы и связи на диаграмме БД, тольк скрипами. Т.е. новые куски схем разрабатывать неудобно. -(+?) Изменения не отражаются на реальных данных продакшена. 2. + "Родной" способ для админов БД. + Требуется только серверная студия, автоматом входящая в ПО. + Таблицы и связи правятся на диаграммах данных - Трудно организовывать объекты по своим функциональным блокам, иерархия будет такой, какая удобна серверу. 3. Мой выбор. + Таблицы и связи правятся на диаграммах данных + Остальные объекты (вью, ф-ии, процедуры) организуются в файлы по функциональным блокам приложения + Можно делать частичный рефакторинг простым текстовым реплейсом, благо в один файл собран код "смежных" объектов - Возможно рассогласование объектов, рефакторинг только частичный, при невнимательности после замены можно получить неправильный код - Риск резать по живому - работаем на продакшене, при работе на девелоперской потом надо повторить изменения на диаграммах и не забыть прогнать измененные файлы на продакшене Продолжение следует... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 11:51 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Как делается по п.3 В рабочем каталоге SQL кода по мере развития системы создаются файлы. Удачно, если получается такая степень группировки объектов, когда в одном файле сидят коды создания всех объектов, обслуживающих данных функциональный блок. Если их слишком много, приходится делать несколько файлов. Внутри файла идут инструкции дроп что-то криейт что-то ... дроп что-то криейт что-то ... дроп что-то криейт что-то ... Ниже по тексту располагаются запросы, зависящие от тех, что выше. Имена объектов обычно получаются добавлением нового слова к уже имеющемуся имени, если новый объект использует (расширяет) предыдущий. Поэтому длинных имен много. Но я предпочитаю побольше нажать букв в пользу бОльшей понятливости названия. В начало файла помещается перечисление всех объектов, в нем написанных. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Каждый объект ниже по файлу снабжается описанием: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
И, наконец, еще ниже код создания объекта Код: 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.
Как-то так... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 12:06 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
П-Л, я правильно понимаю что свои запросы (представления) ты создаешь посредством кода, и не используешь соответствующий конструктор? все мои запросы сделаны в конструкторе. Даже если сам запрос набирался вручную, все равно потом открывал конструктор и вставлял текст запроса. может быть при таком м создании соответствующие файлы генерируются автоматом? Пока из того что ты описал ухватил простую но ясную мысль. Имя запроса создается на основе сущностей к которым он обращается, дальнейшие доработки — дополнения к этому имени. ...хотя как быть если запрос обращается к двум и более другим запросам созданным ранее. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 13:47 |
|
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
|
|||
---|---|---|---|
#18+
Да, вручную мне кажется делать запросы гораздо удобнее. Обычно следующие (ниже по тексту) запросы используют части кода расположенных выше, это удобно копипастить. Самый первый запрос получается перетягиванием полей из таблицы на страницу кода. В этот же момент надо не полениться и скопировать со схемы данных описания полей. Тогда при последующем переклеивании описания тоже будут копироваться во вновь создаваемый код. Файл "компилируется", загоняется в сервер командой RUN целиком. Пока идет работа над текстом объекта его куски можно выделять мышкой и тоже прогонять RUN'ом. Между запросами или в конце файла накапливаются полезные тестовые примеры запуска запросов, функций и процедур, обрамленные комментариями. Это просто одна из возможных практик. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 21:23 |
|
|
start [/forum/topic.php?all=1&fid=45&tid=1619858]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
173ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
81ms |
get tp. blocked users: |
2ms |
others: | 302ms |
total: | 603ms |
0 / 0 |