_модВ то же время классификатор товаров должен быть иерархическим.

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

_мод mcureenab Можно товары классифицировать по разным категориям, но не сооружать из них дерева.
Дело в том, что недерево имеет тенденцию превращаться в дерево (а наоборот нет).

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

Если иерархическая структура имеет ограниченное число ярусов, то её так же не сложно преобразовать обратно в линейную структуру с соответствующим числом классифицирующих атрибутов. Но если число ярусов не ограничено (что практически встречается не часто), то такая структура может быть преобразована в линейную структуру с бесконечным числом классифицирующих атрибутов, но такие структуры не поддерживаются современными СУБД.


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

_мод mcureenab
Извините, ничего не понял. Как дерево преобразовать в список без потери информации о дереве и как из списка построить дерево, не имея такой информации.

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

Обратное преобразования тоже не составляет труда. Например, список
(A, B1, NULL)
(A, B2, C)

преобразуется например в такое дерево:

Petro123Лучше скажите, с практической точки зрения, реализация 2-х классификаторов как признаков места в дереве используется где? Это велосипед или неприменимо?
idTovar klass1 klass223 1 245 1 255 2 256 2 1______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Конечно используется. В моей БД большинство таблиц имеют более одного B*Tree индекса. А индекс чем не классификатор, хотябы на системном уровне.

_мод mcureenab
Теперь понял. Но это просто разные способы представления дерева, а само дерево не перестало существовать.

Применительно к реляционным БД разговоры деревьях не имеют большого смысла, поскольку данные в них представлены в виде реляционных отношений, а древовидные структуры формируются за пределами БД на уровне форм, отчётов и прочих приложений БД. Даже иерархические запросы возвращают не дерево, а определённым образом упорядоченное отношение. Почти любую таблицу можно преобразовать в древовидную структуру, например можно скопировать её в индексно организованную таблицу, тем самым обеспечив хранение данных в виде древовидной структуры.

Что касается проектирования БД, то декомпозиция отношений обычно приводит к логическим связям типа предок-потомок, тем самым образуя иерархию записей в таблицах.

Другой вариант, структуры типа свиное ухо, когда кортеж с многократно повторяющимися группами атрибутов транспонируют так, что каждая группа атрибутов, иногда дополненная суррогатным ключём и соответствующим внешним ключём, становится отдельной строкой в таблице. Приём спорный. Мой опыт показывает, что работать с такими структурами, не смотря на их изящество, достаточно сложно. Особо проблематично работать со структурами, где каждая отдельная запись содержит только часть PK исходного отношения. Т.е. лист в этом дереве идентифицируется всем набором записей которые образуют ветку дерева.

_модНаличие или отсутствие иерархии закладывается на уровне концептуальной модели данных, и лишь затем реализуется в СУБД, интерфейсах, отчетах и пр. Пмсм, автор топика именно это имел ввиду. Т.е., если иерархия изначально не заложена, то потом уже будет поздно, ничего не изменишь.

Если её нет в исходных данных, тогда да, но опять же, если мы можем построить B*Tree индекс, то автоматически получаем некоторую иерархическую структуру, пусть даже бессмысленную с прикладной точки зрения. А если есть, то даже если мы специально не закладывали иерархические связи в модель данных, иерархию можно будет построить когда угодно.