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

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

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

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

• Таблица Alter/create
• Новая форма для фильтрации скручивания жгутов такая категория определенными атрибутами
• Новый код для генерации дб запрашивает для поиска и фильтрации
• Некоторый новый viewmodels/DTOs и представления для представления продуктов от новых категорий

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

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

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

1) Я сохранил бы данные в RDBMS с помощью вида EAV и преодолел бы его проблемы производительности с использованием поиска SOLR (но все еще будут проблемы с беспорядком EAV, никакое осуществление целостности данных и т.д.),

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

Каковы Ваши мысли? Вы думаете, что для какого-либо вида такой (производительной) генерации кода гибкости таксономии неизбежно? Как Вы обработали бы это? Возможно, некоторый отдельный словарь данных способом EAV в DB только в целях генерации кода? Я предполагаю, что мог также использовать что-то как MongoDB, но для генерации кода UI (время выполнения или не) все еще будут нужны некоторые метаданные.

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