Сохранение древовидной структуры в БД

[azamat]

Сохранение древовидной структуры в БД

Господа, возникла проблема следующего плана: существует каталог продуктов (all->categories->type->brand). Проблема в следующем, как организовать дерево, чтобы каталог можно было строить и так:

all->brand->categories->type
all->type->categories->brand

Критично вемя работы скрипта, можно ли это реализовать одним деревом или все таки придется строить их несколько. Буду благодарен за любые советы.

 

[neko]

это не дерево
это сеть

 

[azamat]

Ну ты быстр, у меня еще страница обновиться не успела Тогда может посоветуешь в каком направлении копать.

 

[neko]

незнаю
это можно сильно по разному делать

в принципе если это единственные два представление можно делать одно дерево и его перестраивать
т.е. копии создавать автоматом
будет хорошо с точки зрения скорости, если структура редко изменяется

 

[azamat]

незнаю
это можно сильно по разному делать

Вот я тоже в замешательстве.

Структура вообще не будет меняться, только 2 или три представления, те что я указал выше.
Самый главный критерий при построении скорость.
Объясню поподробнее, может кто-нибудь сталкивался с подобным. Есть магазин с большим количеством продуктов и заказчик хочет, чтобы каталог строился как исходя из типов продуктов так и начиная с производителя, выше я представил примеры структур.

 

[neko]

ну можно при сохранении дерева в одном видет слить это все в плоскую таблицу и перестроить

т.е. то что было ссылкой на родителя станет ссылками на детей

-~{}~ 18.08.04 13:00:

вообще сильно зависит от того как дерево хранится
если как предлагает это делать celko и второй там с украинской фамилией то сложнее получается имхо

 

[WD]

А разве индексирование таблиц по нужным колонкам не решает эту проблему?

 

[azamat]

А разве индексирование таблиц по нужным колонкам не решает эту проблему

Каким это образом?

neko, если не сложно можно ссылку на способ celko и этого со странной украинской фамилией

 

[crocodile2u]

Если структура содержит только

all->brand->categories->type
all->type->categories->brand,

то можно поступить так, обойдясь без деревьев вообще:

1-я таблица - categories
2-я таблица - brand
3-я таблица - type

У табл. categories - внеш. ключи на таблицы brand и type.

???

 

[neko]

crocodile2u
а чем это не дерево

-~{}~ 18.08.04 13:51:

azamat
в гугле

 

[crocodile2u]

Originally posted by neko
crocodile2u
а чем это не дерево

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

 

[azamat]

Прочитал статьи celko, но думаю это не то что мне требуется.
Действительно, какие минусы в варианте предложенном crocodile2u, какие могут быть подводные камни при построении каталога если все его ступеньки хранить в отдельных таблицах:

type
categories
brands

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

 

[neko]

ну если это не то что тебе требуется сделай простую табличку
id | parent id
и еще одну
id | text

и при сохранении правок делай 2 копии первой
на вскидку мне ничего проще не приходит в голову

 

[azamat]

Я это и имел в виду, только без копии таблички, а

id | parent cat1 id | parent cat2 id

id | text

Меня интересовало насколько это грамотно с точки зрения построения БД, ладно, все равно всем спасибо.

 

[neko]

совсем неграмотно

 

[azamat]

Что и требовалось доказать . Я и сам это понимаю каким то шестым чувством, буду мыслить дальше

 

[crocodile2u]

Я вовсе не предлагал хранить все ступеньки каталога в отдельных таблицах - я предложил решение для вполне конкретной задачи (поэтому и приписал - "если структура ограничивается связкой бренд-категория-тип"). А если у тебя структура сложнее (типа есть вложенность категорий или если ты "бренд-категория-тип" только для примера привел ), тогда нужно искать другие решения.

 

[Screjet]

Попробуй составить такой каталог в блокноте, и посмотри на него

 

[IL78]

Осмелюсь поделиться своими соображениями по теме. Что, если абстрагироваться от проблемы "яйцо или курица" (в смысле что во что вложено), и рассмотреть такие составляющие каталога?

1) Однозначно определенное дерево структуры all->category->id;
2) Товар (id) со свойствами brand и type.

Свойства товара не влияют на хранение дерева, но служат для уточняющего ограничения выборки товаров из одной категории. При построении "виртуального подраздела" ИМХО достаточно выбрать товары из данной категории с заданным значением одного свойства, сгрупировав их по значению другого.

Если такой подход в корне неверен, прошу меня извинить, а заодно подсказать, где ошибка в моих рассуждениях.

 

[neko]

IL78
да ошибка в том что ты все переусложнил
задача довольно таки простая
а ты навводил каких-то сущностей лишних