Необходимый совет структуры базы данных

Во-первых, пользовательский интерфейс: как пользователь, которого я ненавижу ] для поиска продукта в каталоге, организованном строго иерархическим способом. Я никогда не помню, в какой подподподподподподкатегории находится «экзотический» продукт, и это заставляет меня тратить время на изучение «многообещающих» категорий только для того, чтобы обнаружить, что он отнесен к категории (для меня, по крайней мере) странным образом.

То, что предлагает Кевин Пено , является хорошим советом и известно как фасетный просмотр . Как Марсия Бейтс написала в После точечной бомбы: получение правильного извлечения информации из Интернета на этот раз , « .. фасетная классификация относится к иерархической классификации, как реляционные базы данных относятся к иерархическим базам данных. . .. ".

По сути, фасетный поиск позволяет пользователям выполнять поиск в вашем каталоге, начиная с любого« фасета », который они предпочитают, и позволяет им фильтровать информацию, выбирая другие фасеты в процессе поиска. Обратите внимание, что вопреки тому, как обычно задуманы системы тегов, ничто не мешает вам организовать некоторые из этих аспектов иерархически.

Чтобы быстро понять, что такое фасетный поиск, есть некоторые демонстрации для изучения на Проект интерфейса поиска Flamenco - потоковые интерфейсы поиска .

Во-вторых, логика приложения: что Manitra proposes также является хорошим советом (насколько я понимаю), т.е. разделение узлов и ссылок дерева / графа в разных отношениях. То, что он называет «таблицей предков» (что, тем не менее, является более интуитивным), известно как транзитивное замыкание ориентированного ациклического графа (DAG) (отношение достижимости). Помимо производительности, он значительно упрощает запросы, как сказал Манитра.

Но я предлагаю представление для такой «таблицы предков» (транзитивное закрытие), чтобы обновления происходили в реальном времени и добавлялись. , а не периодическое издание пакетным заданием. В статьях, которые я упомянул в своем ответе на язык запросов для наборов графов: вопрос моделирования данных , есть код SQL (но я думаю, что его нужно немного адаптировать к конкретным СУБД). В частности, посмотрите Поддержание транзитивного замыкания графов в SQL (.ps - постскриптум).

Связь продуктов и категорий

Первый пункт Manitra также заслуживает внимания.

Он говорит о том, что между продуктами и категориями существует связь «многие-ко-многим». То есть: каждый продукт может относиться к одной или нескольким категориям, и в каждой категории может быть ноль или более продуктов.

Для заданных переменных отношения (relvars) продуктов и категорий такие отношения могут быть представлены, например, как relvar PC с at наименьшие атрибуты P # и C #, т.е. номера продуктов и категорий (идентификаторы) во взаимоотношениях внешнего ключа с соответствующими номерами продуктов и категорий.

Это дополняет управление иерархиями категорий. Конечно, это всего лишь эскиз проекта.

О фасетном просмотре в SQL

Полезной концепцией для реализации «фасетного просмотра» является реляционное деление или даже реляционные сравнения (см. Внизу связанной страницы). Т.е. разделив ПК (Товары-Категории) на (растущий) список категорий, выбранных пользователем (фасетная навигация), можно получить только товары в таких категориях (конечно, предполагается, что категории не все взаимоисключающие, в противном случае если выбрать две категории, то получится ноль продуктов).

СУБД на базе SQL обычно не имеют этих операторов (деления и сравнения), имел дело с иерархическими данными в SQL базы данных и, несомненно, узнал, что управление иерархическими данными не что предназначена реляционная база данных за. Таблицы реляционного база данных не иерархическая (например, XML), но представляют собой простой плоский список . Иерархические данные имеют родительский-дочерний отношения, которые не являются естественными представлен в реляционной базе данных Таблица. ...

Чтобы понять, почему эта настойчивость в отношении плоскостности отношений просто абсурд , представьте себе куб в трехмерной декартовой системе координат : он будет идентифицирован по 8 координатам ( тройки), скажем, P1 (x1, y1, z1), P2 (x2, y2, z2), ..., P8 (x8, y8, z8) [здесь нас не интересуют ограничения на эти координаты, так что они действительно представляют куб].

Теперь мы поместим этот набор координат (точек) в переменную отношения и назовем эту переменную Points . Мы представим значение отношения точек в виде таблицы ниже:

Points|  x |  y |  z |
=======+====+====+====+
       | x1 | y1 | z1 |
       +----+----+----+
       | x2 | y2 | z2 |
       +----+----+----+
       | .. | .. | .. |
       | .. | .. | .. |
       +----+----+----+
       | x8 | y8 | z8 |
       +----+----+----+

Выполняется ли этот куб "сглаженным" простым представлением его в виде таблицы? Является ли отношение (значение) тем же самым, что и его табличное представление?

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

Не поймите меня неправильно, это, безусловно, правда, что SQL - это плохо спроектированный язык, и что СУБД на основе SQL полны идиосинкразии и недостатков (NULL, избыточность, ...) , особенно плохие, тип DBMS-as-dumb-store (без ограничений по ссылкам, ограничений целостности, ...). Но это не имеет ничего общего с выдуманными ограничениями реляционной модели данных, наоборот: чем больше они отворачиваются от нее, тем хуже результат.

В частности, реляционная модель данных, как только вы ее поймете, не представляет проблем с представлением любой структуры, даже иерархий и графиков, как я подробно описал со ссылками на опубликованные статьи, упомянутые выше. Даже SQL может, если скрыть его недостатки, упустить кое-что получше.

По «Модели вложенных множеств»

я бегло просмотрел оставшуюся часть этой статьи , и я не особенно впечатлен такой логический дизайн: он предлагает объединить две разные сущности, узлы и ссылки , в одно отношение, и это, вероятно, вызовет затруднения. Но я не склонен анализировать этот дизайн более тщательно, извините.

EDIT: Стефан Эггермонт возразил в комментариях ниже, что « Модель плоского списка является проблемой. Это абстракция реализации, которая затрудняет достижение производительности. ... ".

Я имею в виду именно то, что:

1. эта« модель плоского списка »является фантазией : просто потому, что один выкладывает (представляет) отношения в виде таблиц (« плоских списков ») ) не означает, что отношения представляют собой «плоские списки» («объект» и его представления - не одно и то же);
2. логическое представление (отношение) и детали физического хранилища (горизонтальная или вертикальная декомпозиция, сжатие, индексы (хэши) , b + tree, r-tree, ...), кластеризация, разбиение и т. д.) различны; одна из точек реляционной модели данных ( RDM ) - отделить логическую модель от "физической". (с преимуществами как для пользователей, так и для разработчиков СУБД);
3. производительность является прямым следствием деталей физического хранилища (реализации) и не логического представления (комментарий Эггермонта является классическим примером логико-физической путаницы ).

RDM модель никак не ограничивает реализации; каждый волен реализовывать кортежи и отношения по своему усмотрению. Отношения не обязательно файлов, а кортежи не обязательно записи файла. Такое соответствие является тупой реализацией прямого изображения .

К сожалению, реализации СУБД на основе SQL слишком часто являются глупыми реализациями прямого изображения и имеют низкую производительность в различных сценарии - OLAP / Продукты ETL существуют для устранения этих недостатков.

Это медленно меняется. Существуют коммерческие и бесплатные программы / реализации с открытым исходным кодом, которые, наконец, избегают этой фундаментальной ловушки:

• Vertica , которая является коммерческим преемником ..
• C-Store: СУБД, ориентированная на столбцы ;
• MonetDB ;
• LucidDB ;
• Kdb в некотором смысле;
• и так далее ...

Конечно, дело в не , что должна существовать «оптимальная» конструкция физического хранилища, но что любая конструкция физического хранилища может быть абстрагирована с помощью хорошего декларативного языка , основанного на реляционной алгебре / исчислениях (а SQL - плохой ) или более непосредственно на языке логического программирования (например, Prolog - см. Мой ответ на вопрос « пролог в конвертер SQL »). Хорошая СУБД должна оперативно менять структуру физического хранилища,