|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
26.11.2002, 14:17:51
|
|||
|---|---|---|---|
|
|||
Опять дерево... |
|||
|
#18+
Доброе время суток! Интересная штучка получается, все что я смог найти по древовидным стуктурам в SQL описывают структуру в которых дочка имеет единственного родителя. А вот в задачке о составе изделия, бывает так, что узел может входить в конечное изделие как в составе другого узла, так и самостоятельно. Причем узел может использоваться в разных изделиях и узлах. Единственный способ, который пригоден (на мой взгляд, может кто другой вариант предложит?) для хранения состава изделия: {родитель; дочка; кол-во} (для листочки дерева: дочка - NULL, кол-во - NULL) А может я все таки неправ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.11.2002, 14:49:13
|
|||
|---|---|---|---|
Опять дерево... |
|||
|
#18+
Это уже не дерево - а сеть :-)). И ничто не мешает Вам хранить информацию о рёбрах(вершинах) графа в двух таблицах: исходящие дуги и заходящие дуги. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.11.2002, 15:01:27
|
|||
|---|---|---|---|
Опять дерево... |
|||
|
#18+
Имхо, для описания BOM дерево подходит больше, чем сеть. Просто нагляднее. Но мне кажется, что не следует идентифицировать узлы дерева с компонентами изделия. Из узлов дерева можно просто ссылаться (foreign key) на возможные компоненты изделия идентифицируемые в другой таблице. При этом разные узлы дерева могут ссылаться на одну и ту же запись в таблице компонентов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.11.2002, 15:08:21
|
|||
|---|---|---|---|
|
|||
Опять дерево... |
|||
|
#18+
А так? create table Items(ii integer) -- детали create table Units(id integer) --готовые изделия, -- могут дублировать Items create table UnitItems( parent int references Units, child int references Items) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.11.2002, 15:54:55
|
|||
|---|---|---|---|
|
|||
Опять дерево... |
|||
|
#18+
2 Sergwsk не совсем понятно чем будут отличатся эти таблицы. Может я чего не понимаю, но для меня исходящие дуги равнозначны входящим (возможно, причина в базовом образовании - физика), ну отличается знаком и все. 2 Chicago ну а если сам компонент (узел, в смысле агрегат) сам состоит из нескольких компонентов и т.д.? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.11.2002, 16:40:11
|
|||
|---|---|---|---|
Опять дерево... |
|||
|
#18+
2Sergey Grigoriev: Граф ориентированный, со стрелками. Например, когда в узле считаются параметры круга заходами будет диаметр и число пи, а исходами, например, длина окружности и площадь круга. В Вашем случае, ИМХО, есть смысловая разница между деталью, входящей в комплект, и отдельно стоящей деталью. Конечно, если Вы не боитесь потерять "семантику" изделия - этой разницей можно пренебречь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.11.2002, 07:50:53
|
|||
|---|---|---|---|
Опять дерево... |
|||
|
#18+
ну а если сам компонент (узел, в смысле агрегат) сам состоит из нескольких компонентов и т.д.? А в чем проблема? Запись соответствующая агрегату/сборке тоже должна присутствовать в таблице компонентов изделия. Вот и все. При этом нужно различать в таблице компонентов неделимые компоненты и агрегаты\сборки (возможна более сложная классификация). В таблице состава изделия разворачивать составляющие агрегатов не нужно. У вас получится набор деревьев высоты 1. Полную детализацию состава изделия проводите только тогда, когда это действительно нужно. Кстати о птичках. Я все это написал и понял: сеть получилась. Узлы сети - записи в таблице компонентов. Отношение компонент А входит в компонент (в данном случае сборку) Б описывается дугой, исходящей из А и входящей в Б. Если из таблицы состава изделия выбрать все записи, у которых parent_id = Б, то мы получаем список всех дуг, заходящих в Б. Таким образом вся таблица состава изделий - это просто набор списков входящих дуг. Имеем набор узлов со списками входящих дуг. А это один из способов задания сети ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.11.2002, 08:59:40
|
|||
|---|---|---|---|
Опять дерево... |
|||
|
#18+
Согласен с бредущим, однако таблица деталей не нужна лучше типизировать Код: plaintext 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. С такой структурой детали могут входить в изделия и наоборот изделия в детали. Сеть ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=46&mobile=1&tid=1818479]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
2ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 342ms |
| 0 / 0 |
