Форум: "Базы";
Текущий архив: 2006.11.05;
Скачать: [xml.tar.bz2];
ВнизСоздание папки в древесной структуре Найти похожие ветки
← →
parovoZZ © (2006-09-05 15:57) [0]Здарова
Ну все знают про возможность оутглюка создавать подпапку в почти любой папке. Вопрос не в том как такое сделать, а как такое хранить в базе? У меня принцип такой
t1 -> t2 -> t3 , но так, что
t3 = t1 + t2
Т.е. при отрисовке дерева сперва рисую все записи из t1. При распахивании узла в подузле рисую только те узлы из t2, на которые есть ссылки из t3 и t1. Ну а при распахивании этого подузла рисую из t3 то, что ссылается на t2 и t1.
Так вот как сюда вставить произвольную папку? Предусмотреть такую возможность и создать в базе ещё одну таблицу с ссылками или создавать таблицу в рантайм по действию пользователя? Мне сказали, что последний вариант признак дурного тона. Но тогда юзер будет ограничен в количестве вложенных папок. Хотя создавать больше одной папки на уровень мне и не надо - помойка выйдет.
← →
Sergey13 © (2006-09-05 16:05) [1]> [0] parovoZZ © (05.09.06 15:57)
Дерево хранится в одной таблице. Два поля - 1=ПК, второе ссылается на 1. Остальные поля по вкусу.
← →
parovoZZ © (2006-09-05 20:40) [2]А, дошло. Получается, что мне нужна ещё одна таблица со ссылками? У меня ж первая таблица - это первый уровень, вторая - второй уровень, третья - третий. Как это уместить в одну таблицу не представляю. К тому же менять существующую структуру таблиц не очень хочется.
← →
parovoZZ © (2006-09-05 22:19) [3]Мысли вслух
Сейчас у меня есть "главная" таблица, по которой строятся ветки второго и третьего уровня. Структура примерно такая
ID (первичный ключ)
name
Sys_ID
Obj_ID
Messages
notes
поле_ID ссылается на соответствующие таблицы с названиями.
Мне же надо создать таблицу примерно такую
ID (родительский ID)
элемент_ID
parent_ID (ссылка на ID родителя или ноль)
таблица_ID (ссылка на таблицу, которая однозначно идентифицирует элемент).
Тогда Obj_ID и Sys_ID из вышеприведённой таблицы можно удалить.
Для построения ветки первого уровня надо найти все элементы, у которых parent_ID = 0. Отсюда два минуса:
1. Жёсткая структура. Родитель и дочерь местами не могут поменяться. Т.е. Класс системы -> объект -> оборудование нельзя отобразить как Объект -> класс системы -> оборудование. Либо, чтобы была такая возможность, организовать ещё одно поле со ссылкой "объект -> класс системы".
Было бы всё хорошо, если бы объекты были без помещений. Поэтому кое-где надо делать так: Класс системы -> объект -> (произвольная группа) -> оборудование (из-за чего, собственно, возник сей топик).
2. У элементов последнего уровня ("оборудование") неизбежно будут плюсики в дереве элементов. Хотя нет. Мне нужно обязательно знать, к чему относятся элементы в поле элемент_ID - либо это класс системы, либо объект, оборудование, либо это произвольная группа. Здесь надо бы покумекать, что писать в поле таблица_ID - либо числовой идентификатор, либо тупо название таблицы, чтобы потом так же тупо вставить в запрос для извлечения названия и другой информации.
Ну что ж, спасибо за подсказку и поправьте меня, где моя не права.
← →
Sergey13 © (2006-09-06 08:52) [4]> [3] parovoZZ © (05.09.06 22:19)
Что-то гложуть меня сомнения - а нужно ли тебе дерево как таковое?
Дерево обычно "сажают" когда уровень вложенности непостоянен и достаточно велик. 3 жестках уровня - это для мастер-детайла задача. ИМХО.
Другое дело если бы ты допустим хотел свои объекты в дерево забубенить. Типа квартира в доме, дом на улице, улица в районе и т.д. Тут да - дерево. А так ...
Ты бы почитал чего по деревьям то. На ibase.ru были несколько статей.
← →
parovoZZ © (2006-09-06 16:22) [5]Дерево - нужно. По крайней мере визуальное. Оборудование определённого класса системы и установлено на определённом объекте.
← →
parovoZZ © (2006-09-07 19:42) [6]А как же быть с названиями таблиц? Число или строка?
← →
parovoZZ © (2006-09-07 22:49) [7]А может тогда объединить три таблицы в одну и будет сквозная нумерация? Но тогда проблема будет с полями, да и про внешние ключи можно забыть. Как быть? Скажите что-нить, а то я тут сам с собой разговариваю.
Не удобно как-то))
← →
Sergey13 © (2006-09-08 01:20) [8]> [5] parovoZZ © (06.09.06 16:22)
Визуально - хоть паровоз. Это не имеет отношения к хранению.
> [6] parovoZZ © (07.09.06 19:42)
В смысле? Table1, Table2 и Table3 - вполне сносные названия. И число и строка присутствуют. 8-)
> [7] parovoZZ © (07.09.06 22:49)
Сквозная нумерация в разных таблицах - кто мешает? Какая проблема с полями? Почему форинкеи забыть?
Я не говорю, что не надо делать "деревянную" таблицу. Можно и сделать. Просто мускул не может (вроде) работать с деревьями как Оракл. И ХП вроде там нет (или уже есть? - не в курсе я). Так что обработать дерево будет проблемматично. А без дерева - стандартный М-Д - проще и понятнее, ИМХО.
Выбирать - дело твое.
← →
parovoZZ © (2006-09-08 10:08) [9]Я имею ввиду ссылку на таблицу как хранить? Название таблицы или ID?
А как сделать форинкей внутри таблицы???
ХП есть, триггеры тоже есть.
Проблема в том, что надо добавить произвольный каталог, причём где-то его может и не быть. Вариант с деревом сам по себе простой, но вот реализация... Да и как найти полный путь до элемента? (до parent_ID = 0)
← →
ANB © (2006-09-08 10:23) [10]
> Да и как найти полный путь до элемента? (до parent_ID =
> 0)
start with . . . connect by
:)
Тебе ж написали, т.к. тебе не нужны крутые деревья без ограничения вложенности, не используй классическое дерево.
А вообще ты хочешь, чтобы тебе БД спроектировали ?
← →
PEAKTOP © (2006-09-08 10:38) [11]Это все строиться на двух таблицах
первая - дерево каталогов (допустим, TABL_TREE)
ID - INTEGER NOT NULL PRIMARY KEY,
NAME - CHAR(N),
PARENT_ID - INTEGER NOT NULL DEFAULT "0" -- FOREIGN KEY особенно не надо, главное - создать индекс по этому полю.
вторая - непосредственно сами сообщения в папках (допустим, TABL_MSG)
TREE_ID INTEGER NOT NULL FOREIGN KEY REFERENCES TABL_TREE(ID),
ID INTEGER NOT NULL PRIMARY KEY,
NAME CHAR(N),
.............
а дерево отображай TDBTreeView (поищи в кладовке где-то тут).
← →
parovoZZ © (2006-09-08 19:13) [12]У меня не_VCL. DBTreeView сейчас реализован, как Вы говорите, мастер-детайлом. А задавая вопрос, я не имел ввиду древовидную структуру данных, а лишь только визуальную часть (та, что в TreeView). А использовать дерево в БД - это Ваша идея.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2006.11.05;
Скачать: [xml.tar.bz2];
Память: 0.49 MB
Время: 0.041 c