|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Всем привет. Есть таблица полуфабрикатов, каждый из которых может содержать как сырье, так и полуфабрикаты. Соответственно, любой из полуфабрикатов может входить в неограниченное количество других полуфабрикатов. Хотелось бы одним запросом (без рекурсий) получать все сырье для определенного полуфабриката, посмотрел структуры для хранения деревьев, но, к сожалению, не нашел такой, которая бы позволяла элементу быть потомком сразу нескольких родителей. Подскажите, есть ли такая структура и где можно про это почитать? Заранее спасиб! ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 08:51 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
пример ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 10:58 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
BOM (Bill of material) такая штука называется. Или спецификация по-русски. Спецификация (Что, Куда, Сколько) КЛЮЧ (Что, Куда). 1 1 12.5 1 2 1000 ... Ищите, найдете непременно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 10:58 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Спасибо, сейчас буду искать ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 11:03 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
У меня вот какая структура: ProjectReceipt - это проект рецептуры ComponentSet - это сырьевой набор рецептуры Raw - это сырье Semiproduct - это полуфабрикаты. Полуфабрикат - формируется из проекта рецептуры, поэтому в таблице есть FK на ProjectReceipt. В состав полуфабриката могут входить другие полуфабрикаты. Причем один и тот же полуфабрикат может входить одновременно в несколько полуфабрикатов. Добавлять еще одну таблицу для создания связи многие-ко-многим - как-то не хочется. Тем более, надо одним запросом получать сырье из сырьевого набора для всех вложенных полуфабрикатов. Для хранения деревьев есть структура с поразрядным ключом , но мне она не совсем подходит, т.к. потомок может иметь только одного родителя, а у меня потомок может иметь нескольких родителей ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 11:58 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Нюанс еще в том, что сначала "появляются" дети, а уже потом для них задается родитель ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 14:19 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Новичок_я. Добавлять еще одну таблицу для создания связи многие-ко-многим - как-то не хочется. Дык куда деваться если связь такая :) Полуфабрикаты и материалы и даже конечные продукты разумно объединить в одну структуру с тем, чтобы они единообразно участвовали в этой и других связях. Тем более, у Вас наверно еще впереди варианты рецептур. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 14:58 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
достаточно трех таблиц и одной процедуры: parts (id, name) -- номенклатура (материалы, ПФ, готовая продукция) bom (id, partid, compid, comptype, partqty,compqty) -- bom (рецептура) mrp(id,comptype,lowlevel,itemid,qty,st) -- результаты расчета сначала в таблицу MRP записывается список продуктов для обсчета, к примеру. Код: plaintext 1.
-- process mrp Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
пример для ms sql. Для другого - изменить процедуру ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 16:22 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Полуфабрикаты и материалы и даже конечные продукты разумно объединить в одну структуру с тем, чтобы они единообразно участвовали в этой и других связях. Тем более, у Вас наверно еще впереди варианты рецептур. Конечный продукты (изделия) объединять с сырьем и полуфабрикатами смысла нет, т.к. это разные сущности, с разными атрибутами. Да и изделия не могут в входить в другие изделия. Получабрикаты и сырье еще можно объединить, но я их разнес по разным таблицам, т.к. схожих у них атрибутов примерно половина. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 06:17 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
iscrafm , Ваша структура мне не подходит: 1. Используется не один запрос. У меня база на акцессе - ХП отпадают :( 2. Я не могу свалить в кучу сырье, полуфабрикаты и изделия _______________ Полуфабрикат создается следующим образом: пользователь разрабатывает проект на полуфабрикат, когда разработка будет закончена - производятся расчеты и добавляется запись в таблицу Semiproduct. Если сделать что-то наподобие SemiproductMap (ID, ID_Child), при добавлении записи в Semiproduct, в эту таблицу для заданного полуфабриката добавлять все(!) вложенные полуфабрикаты, ну например: 1: 2 3 4 - полуфабрикат 1 состоит из 2, 3 и 4 2: 5 7 - полуфабрикат 2 состоит из 5 и 7 4: 5 9 - полуфабрикат 4 состоит из 5 и 9 В таблице SemiproductMap будет: 1 2 1 3 1 4 1 5 1 7 1 5 1 9 И в любой момент можно будет посмотреть полный состав. Насколько плох или неудобен такой вариант? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 06:43 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Новичок_яКонечный продукты (изделия) объединять с сырьем и полуфабрикатами смысла нет, т.к. это разные сущности, с разными атрибутами. Да и изделия не могут в входить в другие изделия. Получабрикаты и сырье еще можно объединить, но я их разнес по разным таблицам, т.к. схожих у них атрибутов примерно половина. Типичная ситуация для типа/супертипа. Важно, что они могут выступать в одной роли в связях. Например, и конечный продукт и сырье и полуфабрикаты могут находиться/перемещаться между цехами, складами. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 11:07 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
ModelR , предложенный Вами вариант не решает главную проблему - как одним запросом получать все вложенные полуфабрикаты? Или я совсем ничего не понял :( ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 11:36 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Не решает. Стандартный SQL этого (рекурсивные запросы) не умеет. iscrafm показал схему процедуры для MS SQL и стандартную технологию: 1) Создаются/меняются спецификации продуктов, полуфабрикатов. Например, изменилась спецификация полуфабриката 2. 2) Выполняется расчет (разузлование) и запоминается Состав изделия в специальной таблице. При расчете изменение спецификации полуфабриката 2 учтется в составе всех нужных нам продуктов и полуфабрикатов, где он участвует. 3) Запросы адресуются к Составу изделия. В ORACLE есть SELECT CONNECT BY, но из-за одного этого платформу менять не стоит. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 14:33 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
приведенный выше мною пример позволяет это сделать. Поля на которые следует обратить внимание: TaskID, Parent, Child, Tree_Left, Tree_Right + почитать про nested sets. Правда при таком подходе придется делать update ключей для всего дерева при добавлении и удалении элементов, а достоинство - в возможности делать выборку одним запросом ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 14:35 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Новичок_я Конечный продукты (изделия) объединять с сырьем и полуфабрикатами смысла нет, т.к. это разные сущности, с разными атрибутами. Да и изделия не могут в входить в другие изделия. Получабрикаты и сырье еще можно объединить, но я их разнес по разным таблицам, т.к. схожих у них атрибутов примерно половина. Изделия, сырье и полуфабрикаты, это как раз одинаковые сущности потому что имеют одинаковые обязательные измерения. А количество доп полей может быть разное, но это совсем не проблема. Доп атрибуты вообще не должны определять сущность, есть одит единственный четко определенный ключ объекта и измерения его описывающие. Вобщем чем дальше влез тем дальше вылез :) Вопрос не в рекурсии, а по нимании, что есть что. Например рецептуры - это нормы, которые действуют определенное время, т.е. это таблица абстрактных правил, в которых участвуют изделия, сырье, полуфабрикаты в определенной пропорции (количественном отношении). Рецепты ни в коем случае не путать с производством. Производство формирует реальные партии товара, а рецепты - только правила списания товаров при приготовлении изделия/полуфабриката. Не вижу вообще мест, в которых нужна рекурсия, потому что это многошаговое производство, в котором не советую миновать многошаговость, а именно и делать многошаговое производство, тогда можно будет контролировать полуфабрикаты на любом шаге приготовления. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 15:39 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
У меня именно рецептуры - т.е. описания и нормы, производства как такового нет. Рецептура описывает, какое сырье и какие полуфабрикаты входят в состав изделия. На каждую рецептуру создается проект - одна таблица как раз и описывает этот проект, неважно, изделие ли это или полуфабрикат. Рекурсия нужна для того чтобы можно было получить сырье из вложенных полуфабрикатов. Посмотрел вариант optimizer'a - вроде бы то, что мне нужно. ModelR2) Выполняется расчет (разузлование) и запоминается Состав изделия в специальной таблице. При расчете изменение спецификации полуфабриката 2 учтется в составе всех нужных нам продуктов и полуфабрикатов, где он участвует. - ну да, я и хотел завести отдельную таблицу, которая бы содержала только структуру вложенных полуфабрикатов. Валентин К Не вижу вообще мест, в которых нужна рекурсия, потому что это многошаговое производство, в котором не советую миновать многошаговость, а именно и делать многошаговое производство, тогда можно будет контролировать полуфабрикаты на любом шаге приготовления. - как Вы уже заметили выше, у меня не производство, а рецептура :) Поэтому рекурсия все же нужна: для обсчета рецептуры мне надо знать, сколько и какого сырья входит во все полуфабрикаты, включая вложенные ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2006, 06:34 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Ну и попутно тогда вопрос: Есть смысл разделять на две таблицы сырье и полуфабрикаты, или поместить в одну? структура такая: Группа сырья -> Подгруппа сырья -> Сырье. Ну например: Мука -> Мука пшеничная -> Мука пшеничная в.с. так вот у полуфабрикатов и сырья есть различия еще и в группах-подгруппах. ранести по разным таблицам - вроде удобнее в использовании, в одну - логически вернее. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2006, 07:47 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
optimizerприведенный выше мною пример позволяет это сделать. Поля на которые следует обратить внимание: TaskID, Parent, Child, Tree_Left, Tree_Right + почитать про nested sets. Правда при таком подходе придется делать update ключей для всего дерева при добавлении и удалении элементов, а достоинство - в возможности делать выборку одним запросомИнтересно. Метод г. Celko (nested sets) именно для деревьев. А БОМ - сеть. Как удалось совместить? Пример Child,Parent,Сколько,Tree_Left, Tree_Right 2,1, 100, ?,? 3,1, 101, ?,? 4,2, 102, ?,? 4,3, 103, ?,? 5,4, 200, ?,? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2006, 14:56 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Для каких целей служит группировка? Является ли она опять же деревом или БОМ? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2006, 15:05 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
забыл указать еще одно ключевое поле: RootKey. Это поле - указатель на корневой элемент, в его проекции получается дерево. В принципе, я не вдавался в суть вопроса поднятого автором, приношу ему свои извинения, если запутал, я показал структуру, которую делал для другой задачи, в которой смоделировал возможность подчинения одного элемента нескольким родителям ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2006, 12:17 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
1. в Access ты от дерева такой полноты не добъёшься 2. как я понял у тебя вершинка может иметь нескольких родителей, тогда Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2006, 16:57 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Новичок_я Валентин К Не вижу вообще мест, в которых нужна рекурсия, потому что это многошаговое производство, в котором не советую миновать многошаговость, а именно и делать многошаговое производство, тогда можно будет контролировать полуфабрикаты на любом шаге приготовления. - как Вы уже заметили выше, у меня не производство, а рецептура :) Поэтому рекурсия все же нужна: для обсчета рецептуры мне надо знать, сколько и какого сырья входит во все полуфабрикаты, включая вложенные Так всем кажется, и мне казалось, пока не разобрался в многошаговом производстве. На деле курсором можно захывтить все шаги за 1 раз и рассчитвать себестоимость всех полуфабрикатов и изделия. Рецептуры и комплектации одинаковы по смыслу, нормы производства немного шире, НО они концептуально похожи и нет необходимости делать различные таблицы для разных типов документов, описывающих правила изготовления. Нет смысла каждый рецепт описывать в одной таблице. Нет смысла держать изделия, полуфабрикаты и сырбе в разных таблицах. По деревьям такой крео > Есть таблицу с древовидной структурой Tree. > Поля таблицы Tree: > ID (целое) - идентификатор объекта > ParentID (целое) - идентификатор "родителя", если верхний уровень, то 0 > Level (целое) - уровень объекта, самый верхний - 0, делее 1,2.... > Path (строка) - самое интересное :) список идентификаторов ВСЕХ родителей через запятую (например 23,15,46,12). Порядок в списке особо не важен > > Запрос пути: > SELECT .... FROM Tree WHERE FIND_IN_SET(ID,ObjPath) ORDER BY Level > > ObjPath - поле Path обекта, путь к котрому надо найти. Если известен только ID объекта, тогда придется сделать два запроса > > SELECT @ObjPath:=Path FROM Tree WHERE ID=ObjID; > SELECT .... FROM Tree WHERE FIND_IN_SET(ID,@ObjPath) ORDER BY Level; > > В результате получим таблицу - список родителей начиная с самого верхнего, заканчивая самым последним. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2006, 15:40 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
И не следует рассмативать процесс изготовления изделия, как дерево. Достаточно действий над партиями и процессингом, все действия линейные и опывают каждый конкрентый шаг изготовления. Для каждого преобразования на 1 тип изделия нужно делать акт изготовления. Можно конечно 1 на несколько и можно его вообще пользователю не показывать, но на практике лучше их генерировать, чтобы пользовательно мог все проверить на калькуляторе и увидеть, ведь в конечном счете пользователи должны пользоваться подобным учетным софтом, а не программеры (для опытов, как надо или как не надо делать)... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2006, 15:46 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Новичок_я, а в чем проблема-то? есть схема хранения дерева, когда при добавлении элемента в дерево в отдельную таблицу прописывается по одной записи на каждый уровень дерева. Пример - есть корень дерева A и у него "потомки" B и С. Мы хотим ввести "потомка" С - D. При этом в таблицу связей попадают две записи (A, D) и (С, D), то есть информация "D является потомком C" и "D является потомком A". Запрос "все потомки данного узла" - при такой структуре получается элементарно, она, в общем, для него и предназначена. В Вашем случае - схема тоже работает, просто в таблицу связей заносится больше записей, если С - потомок не только A, но и A1, а D - не только С, но и С1 - то в таблицу связей попадут (A, D), (A1, D), (C, D), (C1, D). ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2006, 21:09 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
Кот МатроскинМы хотим ввести "потомка" С - D. При этом в таблицу связей попадают две записи (A, D) и (С, D), то есть информация "D является потомком C" и "D является потомком A". Одного только не учли. Чтобы добавить узел, нужно выполнить развертку до этого уровня включительно. Именно об этой развертке и идет речь. Да и хранить все отношения несколько необычно. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2006, 13:19 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
iscrafm Чтобы добавить узел, нужно выполнить развертку до этого уровня включительно. С помощью этой таблицы она выполняется элементарно - все непосредственные родители + все содержимое этой таблицы для каждого из непосредственных родителей, с заменой id потомка на id нового элемента. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2006, 16:29 |
|
Дерево, элемент может быть потомком нескольких родителей(+)
|
|||
---|---|---|---|
#18+
iscrafm достаточно трех таблиц и одной процедуры: parts (id, name) -- номенклатура (материалы, ПФ, готовая продукция) bom (id, partid, compid, comptype, partqty,compqty) -- bom (рецептура) mrp(id,comptype,lowlevel,itemid,qty,st) -- результаты расчета сначала в таблицу MRP записывается список продуктов для обсчета, к примеру. Код: sql 1. 2.
затем запускается приведенная ниже процедура. -- process mrp Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
набор полей естественно минимальный. расширять по необходимости. пример для ms sql. Для другого - изменить процедуру ? Решаю похожую задачу. Наткнулся на пост iscrafm , кто-то может расшифровать таблицу BOM, что такое id, partid, compid, comptype, partqty,compqty и таблицу MRP , что такое id,comptype,lowlevel,itemid,qty,st ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 13:28 |
|
|
start [/forum/topic.php?all=1&fid=32&tid=1539856]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
285ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
others: | 231ms |
total: | 618ms |
0 / 0 |