| |
|
|
| | Может есть у кого опыт решения таких задач...
Есть детали из которых собирают узел. Несколько таких узлов плюс несколько деталей дают изделие. Изделие плюс ещё пару узлов и деталей даёт другое изделие. Как это всё организовать? Как потом обрабатывать эти данные? Допустим потребуется обсчитать сколько болтов в каком-то изделии. Уровень вложенности абсолютно произвольный...
Если кто решал подобные задачи - поделитесь опытом | |
| |
| |
| |
|
|
| | можно почитать и посмотреть примеры по использованию Treeview
хотя произвольный уровень вложенности - это та еще песня | |
| |
| |
| |
|
|
| | Не точно выразился - как структуру таблиц продумать грамотно, чтоб и данные рационально хранились и рационально извлекались | |
| |
| |
| |
|
|
| | в общем-то должно хватить 3-х сущностей:
ParentNodeID - родительский узел
FirstNodeID - первый на уровне
LastNodeID - полседний на уровне
но можно и поизвращаться :) | |
| |
| |
| |
|
|
| | Т.е. ты предлагаешь лить всё в одну таблицу
ParentNodeID понятно. А зачем FirstNodeID - первый на уровне и LastNodeID - последний на уровне? | |
| |
| |
| |
|
|
| | ну если FirstNodeID = null - значит это первый на это уровне, соответственно, если LastNodeID = null - последний | |
| |
| |
| |
|
|
| | >можно почитать и посмотреть примеры по использованию
>Treeview
просмотрел кучу примеров. Там принцип ясно прослеживается - известны родители, а от них уже детки размножаются. У меня случай тяжелее - известны детки, а их немыслимые комбинации должны порождать родителей - о как... | |
| |
| |
| |
|
|
| | мне кажется, что не так
по любому я должен сперва создать родителя, например, автомобиль, потом добавить в него узлы и агрегаты, потом детали.
думается метод drag-and-drop, который поддерживает TreeView, как раз здесь будет уместен | |
| |
| |
| |
|
|
| | А узлы и агрегаты ты где возьмёшь? Сначала создашь, а потом уже добавишь в автомобиль. Вот и получается что сначала дети заносятся, а потом в различных сочетаниях добавляются в родителя. Интерфейс я более-менее представляю, но КАК организовать структуру таблиц не пойму...
Может так. Одна таблица - справочник: комплектующие, расходники. Вторая таблица - сборные изделия, которые формируются из позиций первой таблицы, и третья таблица - описание состава сборного изделия. Вторая с третьей соединены один-ко-многим.
Т.к. какой-то сборный узел может быть комплектующим другого изделия, то при создании сборного узла заносится инфа о названии и составе во вторую и третью таблицы, а так же этот сборный узел вносится в первую таблицу-справочник. И при создании следующего узла этот узел берётся из справочникка | |
| |
| |
| |
|
|
| | таким образом ограничивается уровень вложенности до 3-х
это нормально - нельзя объять необъятное.
да и иерархии как таковой уже нет - есть просто таблицы
 | |
| |
| |
