Я некоторое время думал о моделировании типичного сайта электронной коммерции с eBay-подобной таксономией и атрибутами, зависящими от конкретной категории продукта.
Первой попыткой был выбор между EAV и моделированием наследования таблиц для каждого класса. Я выбрал последнее из-за производительности, но это означало создание отдельной таблицы для каждой конкретной категории (лист в дереве категорий) с определенными атрибутами категории (например, разрешение для телевизоров), смоделированными в виде отдельного столбца.
Несмотря на производительность, эта настройка не является гибкой, если вам нужно добавить атрибуты к существующим категориям или добавить новые категории. Для каждого такого изменения необходимо следующее:
- Изменить / создать таблицу
- Новая форма для фильтрации по такой категории по определенным атрибутам
- Новый код для генерации db-запросов для поиска и фильтрации
- Некоторые новые viewmodels / DTO и представления для представления продуктов из новых категорий
Чтобы справиться с этой сложностью, я думаю, что необходимо какое-то мета-представление этих атрибутов (даже вне приложения) в xml или даже в файле excel, чтобы при каждом изменении весь упомянутый код мог генерироваться автоматически (sql / запросы orm, код приложения, шаблоны). Так что это может помочь в разработке, но все же необходимо тестирование и дополнительное развертывание.
В этот момент я узнал, что ebay на самом деле не использует реляционные БД для поиска, и что их таксономия настолько гибка, что они могут довольно быстро добавлять новые категории листьев. Кроме того, их категории - это, вероятно, не категории из иерархического дерева, смоделированного в реляционной базе данных, а просто атрибуты поиска (фасеты).
После быстрого просмотра наиболее многообещающей специализированной настройки многогранного поиска (отдельного экземпляра Solr) я не уверен, может ли это помочь мне быть гибким к изменениям таксономии, поскольку обычно Solr просто отражает как-то реляционную БД, поэтому конкретные атрибуты категории все еще должны быть смоделированы в БД как метаданные СУБД, например, Динамическое создание форм пользовательского интерфейса для фильтрации атрибутов было бы сложно, если:
1) Я бы сохранял данные в СУБД с использованием EAV fasion и преодолевал проблемы с производительностью с помощью поиска SOLR (но все равно были бы проблемы с беспорядком в EAV, без обеспечения целостности данных и т. Д.)
2) Я бы хранил только словарь атрибутов (т. Е. Только их имена и типы) в СУБД и сохранял значения конкретных атрибутов в SOLR, используя его как хранилище нереляционных данных отдельно от средства поиска. Я также не убежден в этом решении (даже если это возможно), поскольку приложение будет тесно связано с solr (т. Е. Администратор CRUD редакции продукта будет напрямую взаимодействовать с SOLR).
Что ты думаешь? Считаете ли вы, что для любого вида такой (эффективной) таксономии гибкость генерации кода неизбежна? Как бы вы справились с этим? Может быть, какой-то отдельный словарь данных в формате EAV в БД только для целей генерации кода? Думаю, я мог бы также использовать что-то вроде MongoDB, но для генерации кода пользовательского интерфейса (во время выполнения или нет) все равно потребуются какие-то метаданные.
Здесь много вопросов, но я не хотел разбивать их на более мелкие вопросы, поскольку меня интересует общий подход к проектированию при работе с большим классом таких проблем.