Во-первых, пользовательский интерфейс: как пользователь I ненавижу для поиска товара в каталоге, организованном строго иерархическим способом. Я никогда не помню, в какой категории sub-sub-sub-sub ...- "экзотический" продукт, и это вынуждает меня тратить время на изучение "многообещающих" категорий, просто чтобы обнаружить, что он относится к категории (для меня, по крайней мере, ) странным образом.
То, что Кевин Пено предлагает, является хорошим советом и известно как граненый просмотр . Как писал Марсия Бейтс в После того, как точечная бомба: Получение доступа к веб-информации прямо на этот раз , « ..» - это иерархическая классификация, а реляционные базы данных - иерархические базы данных. . ..".
По сути, граненый поиск позволяет пользователям выполнять поиск в вашем каталоге, начиная с любого «фасета», который они предпочитают, и позволяет им фильтровать информацию, выбирая другие фасеты в процессе поиска. Обратите внимание, что вопреки обычному пониманию систем тегов, ничто не мешает вам организовать некоторые из этих аспектов иерархически.
Чтобы быстро понять, что такое граненый поиск, есть несколько демонстраций для изучения на Проект интерфейса поиска Flamenco - Интерфейсы поиска, которые текут .
Во-вторых, логика приложения: то, что предлагает Manitra , также является хорошим советом (насколько я понимаю), то есть разделение nodes и links дерева / графа. в разных отношениях. То, что он называет «таблицей предков» (однако это гораздо более интуитивное имя), известно как транзитивное замыкание ориентированного ациклического графа (DAG) (отношение достижимости). Помимо производительности, он значительно упрощает запросы, как сказал Манитра.
Но Я предлагаю представление для такой «таблицы предков» (транзитивное замыкание), чтобы обновления выполнялись в режиме реального времени и постепенно, а не периодически с помощью пакетного задания. В статьях, которые я упоминал в своем ответе на язык запросов для наборов графов: вопрос моделирования данных , есть код SQL (но я думаю, что его нужно немного адаптировать к конкретным СУБД). В частности, посмотрите Поддержание транзитивного закрытия графиков в SQL (.ps - postscript).
Продукты-Категории отношений
Первый пункт Манитры также заслуживает внимания.
Он говорит о том, что между товарами и категориями существует отношение «многие ко многим». Т.е. каждый товар может относиться к одной или нескольким категориям, а в каждой категории может быть ноль или более товаров.
Для заданных переменных отношений (relvars) продуктов и категорий такие отношения могут быть представлены, например, как relvar PC с по крайней мере атрибутами P # и C #, то есть номерами продуктов и категорий (идентификаторами) в отношениях внешнего ключа с соответствующими Номера продуктов и категорий.
Это дополняет управление иерархиями категорий. Конечно, это всего лишь эскиз дизайна.
О граненом просмотре в SQL
Полезной концепцией для реализации "граненого просмотра" является реляционное деление или, даже, реляционное сравнение (см. Нижнюю часть связанной страницы). То есть разделив ПК (категории продуктов) на (растущий) список категорий, выбранных пользователем (фасетная навигация), можно получить только продукты в таких категориях (конечно, категории предполагаются , а не все взаимоисключающие, в противном случае выбирается две категории одна получит ноль продуктов).
СУБД на основе SQL обычно не имеют этих операторов (деление и сравнение), поэтому ниже я приведу несколько интересных статей, которые их реализуют / обсуждают:
и так далее ...
Я не буду здесь вдаваться в подробности, но взаимодействие между иерархиями категорий и просмотром фасетов требует особого внимания.
Отступление на «плоскостность»
Я кратко посмотрел статью, связанную с Pras , Управление иерархическими данными в MySQL , но я перестал читать после нескольких строк во введении:
Введение
Большинство пользователей в то или иное время имеют
имеет дело с иерархическими данными в SQL
базы данных и, без сомнения, узнали, что
управление иерархическими данными не
что такое реляционная база данных
за. Таблицы реляционных
базы данных не являются иерархическими (например,
XML), но это просто плоский список .
У иерархических данных есть родитель-потомок
отношения, которые не являются естественными
представлены в реляционной базе данных
Таблица. ...
Чтобы понять, почему это требование настойчивости отношений просто бессмыслица , представьте куб в трехмерной декартовой системе координат : он будет идентифицирован 8 координатами (триплетами), скажем, P1 (x1, y1, z1), P2 (x2, y2, z2), ..., P8 (x8, y8, z8) [здесь мы не имеем дело с ограничениями на эти координаты, чтобы они действительно представляли куб] .
Теперь мы поместим этот набор координат (точек) в переменную отношения и назовем эту переменную Points. представим значение отношения Points в виде таблицы ниже:
<b>Points</b>| <b>x</b> | <b>y</b> | <b>z</b> |
=======+====+====+====+
| x1 | y1 | z1 |
+----+----+----+
| x2 | y2 | z2 |
+----+----+----+
| .. | .. | .. |
| .. | .. | .. |
+----+----+----+
| x8 | y8 | z8 |
+----+----+----+
Разве этот кубик "сплющивается" простым актом представления его в табличной форме? Отношение (значение) - это то же самое, что и его табличное представление?
Переменная отношения предполагает в качестве значений наборы точек в n-мерном дискретном пространстве, где n - количество атрибутов отношения («столбцов»). Что значит для n-мерного дискретного пространства быть «плоским»? Просто чепуха, как я писал выше.
Не поймите меня неправильно. Конечно, SQL - это плохо спроектированный язык и что СУБД на основе SQL полны идиосинкразий и недостатков (NULL, избыточность, ...), особенно плохих, СУБД -as-dumb-store type (без ссылочных ограничений, без ограничений целостности, ...). Но это не имеет ничего общего с воображаемыми ограничениями реляционной модели данных: наоборот, чем больше они отворачиваются от нее, тем хуже результат.
В частности, реляционная модель данных, как только вы ее понимаете, не представляет проблемы в представлении какой-либо структуры, даже иерархий и графиков, как я подробно описал со ссылками на опубликованные статьи, упомянутые выше. Даже SQL может, если вы замаскируете его недостатки, упустить что-то лучшее.
В модели "Вложенный набор"
Я просмотрел остальную часть этой статьи , и меня не особо впечатлил такой логический дизайн: он предлагает запутать два разных объекта: узлы и ссылки , в одно отношение, и это, вероятно, вызовет неловкость. Но я не склонен анализировать этот дизайн более тщательно, извините.
РЕДАКТИРОВАТЬ: Стефан Эггермонт в комментариях ниже возразил, что " Модель плоского списка является проблемой. Это абстракция реализации, которая затрудняет достижение производительности. ...".
Теперь моя точка зрения такова:
- эта "модель плоского списка" является фантазией : только то, что один выкладывает (представляет) отношения в виде таблиц ("плоских списков"), не означает, что отношения являются "плоскими списками" (объектом) "и его представления не одно и то же);
- логическое представление (отношение) и физические детали хранения (горизонтальная или вертикальная декомпозиция, сжатие, индексы (хеши, b + дерево, r-дерево, ...), кластеризация, разбиение и т. Д.) Различны; одна из точек реляционной модели данных ( RDM ) состоит в том, чтобы отделить логическую модель от «физической» (с преимуществами как для пользователей, так и для разработчиков СУБД);
- является прямым следствием подробностей физического хранения (реализация), а , а не логического представления (комментарий Эггермонта является классическим примером логически-физического смешения ).
Модель RDM никоим образом не ограничивает реализации; каждый может свободно использовать кортежи и отношения по своему усмотрению. Отношения - это , не обязательно файлы, а кортежи - , не обязательно записи файла. Такое соответствие является тупой реализацией прямого изображения .
К сожалению, реализации СУБД на основе SQL - это , слишком часто глупые реализации с прямым изображением, и они страдают от низкой производительности в различных сценариях - OLAP / ETL существуют продукты для устранения этих недостатков.
Это медленно меняется. Существуют коммерческие и свободные реализации программного обеспечения / с открытым исходным кодом, которые в конце концов избегают этой фундаментальной ошибки:
Конечно, суть не в том, что должен существовать «оптимальный» дизайн физической памяти, но в том, что любой дизайн физической памяти может быть абстрагирован хорошим декларативным языком на основе по реляционной алгебре / исчислениям (а SQL - это плохой пример) или, более точно, по языку логического программирования (например, Пролог - см. мой ответ на « преобразователь пролог в SQL » вопрос). Хорошая СУБД должна оперативно изменять дизайн физической памяти, основываясь на статистике доступа к данным (и / или подсказках пользователя).
Наконец, в комментарии Эггермонта утверждение " реляционная модель оказывается зажатой между облаком и превейлером. " - еще одна чепуха, но я не могу дать здесь опровержение, этот комментарий уже слишком длинный.