Хранение дерева данных в базе

← →
Shade_ © (2004-05-16 02:33) [0]

1 Каким образом хранится дерево данных в базе данных?
2 Какой тип таблиц для этого используется?
3 Какой движок БД нужен?
4 За структурой дерева смотрит БД или ручками?

← →
muk07 (2004-05-16 07:53) [1]

1)Пример - классификация.
в нотации Transact SQL:
create table Tree(
Self_ID identity(1,1) primary key, -- собственнный ключ
Parent_ID int null foreign key references Tree(Self_ID), -- ссылка на родительскую запись. null - потому что корень не имеет родителя
bit IsLeaf, -- запись является листом - дальше дерево не ветвится
Info <любой тип> -- прочие данные
)

2)типе таблиц вопрос непонятен - обычная таблица
3)Что такое движок? СУБД - любая
4)Тоже непонятно - что значит "смотреть за структурой"
3) В приведенном примере СУ

← →
muk07 (2004-05-16 07:53) [2]

← →
Ihor Osov'yak © (2004-05-17 02:04) [3]

2 muk07

Имхо, bit IsLeaf - лишнее.

← →
Petr V. Abramov © (2004-05-17 02:39) [4]

Ihor Osov"yak © (17.05.04 02:04) [3]
IMHO, не всегда :)

← →
Ihor Osov'yak © (2004-05-17 02:57) [5]

2 [4] Petr V. Abramov © (17.05.04 02:39)

Ну почему же? Выборка на тему - "если ли детки" будет выполнятся быстро - поле все же индексированное. Если все же вопрос в быстродействии - я бы все же дал предпочтение непротиворечивой структуре и отсутствием соотв. геморою по сравнению с сомнительным выиграшем в быстродействии. В крайнем слцчае просто бы сделал вычисляемое поле, или работал бы через View, там, где такое поля якобы бы нужно.
Если же нужно некий флаг, говорящий "деток быть не должно" - имя поля следовало дать бы по другому, чтобы вопросов не возникало, например - disableChild.. Или что-то в этом роде. В английском я не очень, возможно есть более красивые варианты наименований..

← →
muk07 (2004-05-17 08:38) [6]

to Ihor Osov"yak :
Представьте себе классификацию товаров. На верхних уровнях - категории, листья - конкретные товары. Я должен знать категория это или товар. Тот факт, что узел - лист еще не означает что это товар. Возможно еще не завершен ввод ветви дерева.

← →
Andriano (2004-05-17 08:46) [7]

Вот здесь посмотри
http://www.ibase.ru/develop.htm

(ID, PARENT_ID, DATA) - это и ежу понятно.
Далее надо вытаскивать всю ветку, получать полное имя и т.п. необх. сервисы реализовать. Самое сложное, конечно, получать всю ветку с детьми. Как это сделать - дело вкуса. Я сделал с помощью рекурсии.

← →
Danilka © (2004-05-17 08:52) [8]

[6] muk07 (17.05.04 08:38)
Так сделано в 1С, но это очень не правильно. Правильно категорию вынести в отдельную таблицу, т.к. у категории и у товара разные свойства - разный набор полей. Почитай про нормальные формы.

← →
muk07 (2004-05-17 10:51) [9]

Нормальные формы это не священная корова. Программист должен в первую очередь жалеть себя, а не дисковое пр-во. Нескромно предлагать что - то почитать про нормальные формы. Есть шанс напороться на грамотного.

← →
Danilka © (2004-05-17 11:02) [10]

[9] muk07 (17.05.04 10:51)
> Нормальные формы это не священная корова.

И что? Даже если забыть про нормализацию, просто по-логике, какой смысл пихать в одну таблицу группу и элементы группы, добалвять в нее все поля необходимые для группы плюс все поля необходимые для элемента, плюс еще одно доп. поле - признак группа/негруппа?
Какая от этого выгода? В чем может быть выигрыш по-сравнению с тем, если их разделить на две таблицы?

← →
Курдль © (2004-05-17 11:14) [11]

Это называется "отношение многие-к-одному" структурированной таблицы самой к себе:
__________________ | | o | /|\ - "многие" V - "к одному" ______________________ | ТАБЛИЦА 1 | |______________________| |TBL_ID - Перв.ключ | |TBL_ID_PR - Внеш.ключ | |______________________|

Создается, заполняется и удаляется структура "ручками" а за целостностью данных следит БД. Т.е. она не даст удалить запись, у которой есть подчиненные записи (без специального на то объявления).

"Движок" - любой. Однако лучше сразу брать самый простой, но "клиент-сервер" (дисциплинирует).

← →
Курдль © (2004-05-17 11:39) [12]

> Нормальные формы это не священная корова. Программист должен
> в первую очередь жалеть себя, а не дисковое пр-во.

Нормальные формы берегут не дисковое пространство, в первую очередь, а целостность данных! Рано или поздно найдется умник, который из другого модуля будет прописывать поле "НЕ_ВЕТВИТСЯ" (для каких-то своих нужд) в то время как подчиненные записи уже есть. И СУБД не отследит такую ошибку!

← →
Cranium © (2004-05-17 14:59) [13]

Я для чебя решил этот вопрос так: Основная таблица в ней храняться сведенияю о сущностях (скажем о товаре) , обязательное поле ID первичный ключ. Вторая таблица(или таблицы так как можно использовать несколько классификаций) В ней то же поле ID уникальный первичный ключ, поле тип записи (сущность или группа), далее поля по вкусу и необходимости....

← →
Курдль © (2004-05-17 15:23) [14]

> Я для чебя решил этот вопрос так:

А я для себя решаю конкретно на основе каждого проекта! Если нет нужды городить лишние таблицы - не горожу и никому не советую.

← →
Shade_ © (2004-05-18 05:03) [15]

Я конечно в этом пока ещё ламер, но если например структуру дерева хранить в обычном файле (SaveToFile). Конечно используя компонент TTreeView. Где все ветки это уникальные ключи. А при открытии дерева отображать эти ветки записями из таблицы, соответствующим ключам. Прога всё равно локальная у меня, так что мороки с передачей структуры дерева возникать не будет. В дальнейшем вообще можно не в файл структуру сохранять, а тоже в таблицу(новую) её структура думаю будет не сложная.

Кто что по этому поводу думает???

← →
atruhin © (2004-05-18 06:27) [16]

то Danilka © (17.05.04 08:52) [8]
>>Так сделано в 1С, но это очень не правильно.
Такой подход применяется очень часто. Например меню ресторана.
Есть 10-20 групп блюд(возможно вложенных), далее идут блюда, но блюда могут включать в себя другие блюда (картофель жареный с луком - это и блюдо и элемент другого блюда - кальмар фаршированный с гарниром).
таблица так и так иерархическая 500-1000 наименований из них 20 групп т.е. записей содержащих название а всё остальное пустое. Если все в одной таблице то мы получаем и обрабатываем дерево одной процедурой, если разнести в разные то нужно сначало запрашивть и обрабатывать группы, потом листья - гемору в цать раз больше.

← →
atruhin © (2004-05-18 06:29) [17]

← →
Danilka © (2004-05-18 08:14) [18]

[17] atruhin © (18.05.04 06:29)

> гемору в цать раз больше.

Да в чем-же гемор-то? Кто-нибудь мне объяснит? Ну текст запроса, который данные достает для построения дерева будет немного больше и все.
Кроме того, в приведенном примере эффективней будет другая структура:
1. Таблица блюд, состоящая из полей: id, parent_id, name
2. Таблица комплектующих которая состоит из полей: id и все остальные поля, которые нужны для нижних веток.
Эти таблицы связаны по полю id. А то, что где-то "Такой подход применяется очень часто.", мне жалко эти места.

2atruhin © (18.05.04 06:29) [17]
Для твоего примера как раз удобнее несколько таблиц. Если гарнир может быть и как самостоятельное блюдо и входить в несколько других, плюс в состав комплексных обедов - нет смысла дописывать его каждый раз как новую сущность. Достаточно указать в дереве групп ссылку на составляющие.
Такой подход более универсален, т.к. позволяет строить "неправильные" деревья, т.е. когда у одного потомка может быть несколько родителей - очень полезная штука в реальной жизни.
А про гемор - проще на счетах работать - полная универсальность. 8-)

[19] Sergey13 © (18.05.04 08:21)
> Если гарнир может быть и как самостоятельное блюдо и входить
> в несколько других, плюс в состав комплексных обедов - нет
> смысла дописывать его каждый раз как новую сущность.

Хм, действительно, тут еще и эта беда. Слона-то я и не приметил..

А я что не понял, все тут про какие то блюда толкуют... Чего голодные что ли?
А как на счёт моего супер дерева, со структурой во внешнем файле.

> Хранение дерева данных в базе

> А как на счёт моего супер дерева, со структурой во внешнем
> файле.

Так в базе или в файле?

To Курдль[22] Так я вот и не знаю как лучше. Про файл я сам придумал. А как в базе ума не приложу. Вообще почему до сих пор единого стандарта не придумают! :(((

Как лучще для твоей конкретной задачи - это уж ты решай сам. Если это курсовая - то и файл сгодится (но для начала подумай - что ты с этими данными делать собираешься - только хранить и больше ничего? никак эту информацию не обрабатывать?), но если реальная задача - даже не думай об этом.

2Shade_ © (19.05.04 03:16) [23]
>Вообще почему до сих пор единого стандарта не придумают! :(((
Вот ты и придумай. Про файл же придумал. А БД тоже файл(ы), только специфический. 8-)

To Sergey13 [25] Чего я тебе гений что ли??? Я пока не волшебник, я только учусь! :)))

Хранение дерева данных в базе Найти похожие ветки