Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
Shade_ © (2004-05-16 02:33:00)
1 Каким образом хранится дерево данных в базе данных?
2 Какой тип таблиц для этого используется?
3 Какой движок БД нужен?
4 За структурой дерева смотрит БД или ручками?

Shade_ (2004-05-23 07:40:00) [1]
To Sergey13 [25] Чего я тебе гений что ли??? Я пока не волшебник, я только учусь! :)))

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

Наталия (2004-05-19 07:29:00) [3]
Как лучще для твоей конкретной задачи - это уж ты решай сам. Если это курсовая - то и файл сгодится (но для начала подумай - что ты с этими данными делать собираешься - только хранить и больше ничего? никак эту информацию не обрабатывать?), но если реальная задача - даже не думай об этом.

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

Курдль (2004-05-18 15:23:00) [5]

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

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

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

Shade_ (2004-05-18 12:38:00) [6]
А я что не понял, все тут про какие то блюда толкуют... Чего голодные что ли?
А как на счёт моего супер дерева, со структурой во внешнем файле.

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

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

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

Danilka (2004-05-18 08:14:00) [9]
[17] atruhin © (18.05.04 06:29)

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

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

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

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

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

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

Курдль (2004-05-17 15:23:00) [13]

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

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

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

Курдль (2004-05-17 11:39:00) [15]

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

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

Курдль (2004-05-17 11:14:00) [16]
Это называется "отношение многие-к-одному" структурированной таблицы самой к себе:
__________________ | | o | /|\ - "многие" V - "к одному" ______________________ | ТАБЛИЦА 1 | |______________________| |TBL_ID - Перв.ключ | |TBL_ID_PR - Внеш.ключ | |______________________|

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

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

Danilka (2004-05-17 11:02:00) [17]
[9] muk07 (17.05.04 10:51)
> Нормальные формы это не священная корова.

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

muk07 (2004-05-17 10:51:00) [18]
Нормальные формы это не священная корова. Программист должен в первую очередь жалеть себя, а не дисковое пр-во. Нескромно предлагать что - то почитать про нормальные формы. Есть шанс напороться на грамотного.

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

Andriano (2004-05-17 08:46:00) [20]
Вот здесь посмотри
http://www.ibase.ru/develop.htm

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »