Различные типы нодов в дереве.

[Bred Vilchec]

Различные типы нодов в дереве.

Здравствуйте.

Проектирую каталог товаров. Товары, разумеется, объединяются в категории,
но помимо категорий товары могут входить и в, так скажем, группы.
Между категорией и группой есть различия, но не думаю, что вам это будет интересно.
Необходимо построить _общее_ дерево (я сейчас остановился на Adjacency List - структуре) для категорий и групп.
Думаю, что по теории РБД правильнее будет разделить эти две сущности в две таблицы, но не могу сообразить как тогда организовать древовидную структуру в двух таблицах. И корее всего получится это слишком сложно.
Пришел к другому варианту, который вроде бы не очень красивый. Дерево будет храниться в одной таблице, но в ней будет присутствовать дополнительное поле - `type` - тип.
Type = 'c' - категория; type = 'g' - группа.

Что посоветуете, уважаемые?

 

[Popoff]

Необходимо построить _общее_ дерево

Что это значит?

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

Ну почему же. Как раз очень интересно. Именно от этих различий зависит вся организация.

 

[Bred Vilchec]

1) Это значит, что и группы, и категории будут узлами одного дерева. По-меому я вполне ясно выразился.

2) Например, таблица категорий товаров будет связана с таблицей параметров товаров, т. е. категория содержит в себе параметры её товаров. А группа похоже содержит только свое имя. Таким образом, таблицы групп и категорий должны выглядеть примерно одинаково: cat_id/group_id; parent_(cat/group)_id; name.

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

Вообщем вариант с type - меньшее из зол.

 

[neko]

ничего плохого в этом нет
узел это узел
а какие на нем сателлитные данные это не имеет значения

и таблицу с узлами разибвать естественно не нужно

 

[Popoff]

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

 

[Bred Vilchec]

neko
Ок, спасибо. Такого ответа я и ожидал.

Popoff
Ну, про пустые параметры - это не в кассу. Параметры будут не полями таблицы категорий, а содержимым таблицы параметров.

 

[Allan Stark]

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

У меня есть рабочий вариант такой методики... Делал когда-то на заказ. Ничего сложного. Есть и удобства - например ф-ции преобразования Name группы в ее ID для поиска по товарам, их сортировки и прочая.

Или я неправильно вас понял ?

 

[Popoff]

Allan Stark
На вкус и цвет товарища нет. Каждый реализует так, как ему удобнее. Можно так, а можно эдак. Нет никаких объективных данных, что один из методов лучше, а другой хуже. Есть только субъективные мнения каждого в отдельности.