Выделенная грантовая поисковая система для работы с динамическими таксономиями - помогает только с эффективностью или гибкостью?

Question

Я некоторое время думал о моделировании типичного сайта электронной коммерции с подобной ebay таксономией и атрибутами, зависящими от определенной категории продукта.

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

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

• Alter/создать таблицу
• Новой формы для фильтрации жгутов такой категории по специфическим атрибутам
• Нового кода для генерации БД запросов для поиска и фильтраций
• Некоторых новых ViewModels/DTO и представления для представления продуктов из новых категорий

Чтобы справиться с такой сложностью, я думаю, что требуется какое-то мета-представление этих атрибутов (даже вне приложение) в файле xml или даже excel, так что при каждом изменении все упомянутые коды могут быть автоматически сгенерированы (запросы sql/orm, код приложения, шаблоны). Таким образом, это может помочь в разработке, но для этого требуется тестирование и дополнительное развертывание.

В этот момент я узнал, что ebay действительно не использует реляционные db для поиска и что их таксономия настолько гибка, что они могут быстро добавить новые категории листьев. Кроме того, их категории не являются категориями из иерархического дерева, смоделированного в реляционном db, а только для атрибутов поиска (граней).

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

1) Я бы сохранил данные в РСУБД с помощью EAV fasion и преодолел проблемы с производительностью с помощью поиска SOLR (но все же были проблемы с бесполезностью EAV, без данных целостность и т. д.)

2) Я бы сохранил только словарь атрибутов (т. е. только их имена и типы) в СУРБД и сохранил определенные значения атрибутов в SOLR, используя его как не-реляционное хранилище данных, кроме объекта поиска , Я также не убежден в этом решении (даже если это возможно), поскольку приложение будет тесно связано с solr (т.е. версия продукта admin CRUD будет взаимодействовать с SOLR напрямую).

Что вы думаете? Считаете ли вы, что для любого типа (результативной) таксономии гибкость генерации кода неизбежна? Как бы вы справились с этим? Может быть, какой-то отдельный словарь данных в модуле EAV в БД только для целей генерации кода? Думаю, я мог бы использовать что-то вроде MongoDB, но генерация кода пользовательского интерфейса (время выполнения или нет) все равно потребует каких-то метаданных.

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

Answer 1

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

1. Я бы забыл о моделировании этого на СЧС. Faceted search just doesn't work in a relational schema.
2. IMO это не подходящее место для генерации кода. Вы должны разработать свой код, чтобы он не менялся с изменениями данных (я не говорю о схеме изменений).
3. Сохранение метаданных/атрибутов в электронной таблице Excel представляется очень плохой идеей. Я бы создал пользовательский интерфейс для редактирования, который будет храниться в Solr/MongoDB/CouchDB/независимо от того, что вы решите управлять этим.
4. Solr не «просто зеркало реляционной БД». Фактически, Solr полностью не зависит от реляционных баз данных. Одним из наиболее распространенных случаев является сбрасывание данных из РСУБД в Solr (денормализация данных в процессе), но Solr достаточно гибкий, чтобы работать без какого-либо реляционного источника данных.
5. Hierarchical faceting in Solr по-прежнему остается открытой проблемой в исследованиях. В настоящее время существуют два отдельных подхода исследуются (SOLR-64, SOLR-792)

Answer 2

Что делать, если у вас разные типы категорий для различных видов продукции?

На примере eBay, мы бы продукты, которые могут быть либо Книги или ТВ/Дисплеи.

Книги имеют название и ISBN, и могут быть в научной категории, или в эротической категории, или в категории научной литературы, или в автобиографической категории. Или, может быть, у вас есть книга, которая находится в неигровой, автобиографической эротической категории.

Дисплеи имеют разрешение экрана и потребляемую мощность (?) И могут быть в категории плоских экранов, категории ЭЛТ или категории HD.

С чисто реляционной точки зрения, вы могли бы возможно модель это так:

[Product]-(1)------(1)-[ Book ]-(n)------(m)-[ book_category ] 
| id |    | title |    | name   | 
| price |    | ISBN | 
| ... | 
| ... |-(1)---(1)-[ display ]-(n)------(m)-[ display_category ] 
        | resolution |    | name   | 
        | watts | 

Вместо моделирования attributes dependent on a particular product category, вы бы иметь различные свойства и категории зависимые от типа/класса продукта.

См supertypes & subtypes