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

Fire Fenixsphinx_mvпропущено...

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

Проясните детальнее пожалуйста свою позицию.
Перемещение сотрудника по филиалам крупной компании.
Примерно такая иерархия: "Страна"->"Город"->"Офис"->"Отдел"->Сорудник.
К тому же на уровнях "Город", "Офис", и "Отдел" могут иметься дополнительные однотипные подуровни

Ivan Duraksphinx_mvпропущено...

Интересно, что скажут коллеги, когда в одном дереве нужно будет хранить иерархии разнотипных сущностей...
С разным назначением... С разными наборами атрибутов и т.п...
а почему нет? назначение нам вообще пофиг, наборы атрибутов - вынесены же!!
Я примерно про то же...
В зависимости от корневого родителя мы можем строить множество разнотипных иерархий в одном дереве.
Или просто добавив признак "тип дерева" просто строим параллельные и независимые иерархии.

guest_20040621> в одном дереве нужно будет хранить иерархии разнотипных сущностей

В правильно спроектированной базе данных все иерархии однородны.
И в чем Вы наблюдаете противоречие?

guest_20040621> И в чем Вы наблюдаете противоречие?

Однородность не предполагает дополнительной категоризации.
Намекаете, что EAV-like-сущности в дерево объединять "низ-з-з-зя"... Ибо "категоризация не предполагается"...
Заблуждение, однако...

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

Если же Вы предполагаете "однородность" как "однородность первичных ключей", то никакого противоречия в "разнотипных" узлах дерева не наблюдается...

ViPRossphinx_mv,

нафиг не нужно работать нетипизированными сущностями

Если уж мы все-таки про БД(ака, "базы данных" ), то нечто, оперирующее нетипизированными сущностями как "базу данных" классифицировать весьма проблематично... Соответственно, к теме это Ваше утверждение совершенно никаким боком.
В-общем, я не понял, в чем Вы меня убеждаете... И почему именно меня...

ViPRossphinx_mv,

Я просто сказал, что в РБД нет никаких деревьев и каталогов
"А мужики-то и не знают!.." (с)
Цепочка связанных таблиц вида T1->T2->...->TN представляет собой по сути ничто иное, как реализацию дерева с ограниченным количеством уровней вложенности. При этом никакая теория не запрещает практическую реализацию подобной цепочки на основе таблицы, записи которой ссылаются на другие записи этой же самой таблицы, получив при этом дерево с неограниченным уровнем вложенности. И "отсутствующие в теории" каталоги - не более, чем узлы дерева определенного типа или имеющие определенный признак (что по сути одно и то же).
"Деревья" и "каталоги" - не более чем еще один из вариантов абстракции и представления взаимосвязей между данными.