eav? партиционирование может какое...
Первое правило работы с EAV - не использовать EAV Можно сделать view на left join-ах и искать в ней. Постепенно придёт осознание)
Интересное утверждение. А как в интернет-магазине сделать, чтобы менеджеры могли для типов товаров самостоятельно свойства задавать, а потом их указывать в товарах?
Почитайте популярные статьи https://habr.com/ru/post/475178/ https://habr.com/ru/post/657895/
Бери большэ -- кидай дальшэ, пока летит -- отдыхай.
В json-ах храните. А, уже посоветовали
И какое тут удобство перед EAV?
Там тожэ всё плохо, и неясно, где хужэ.
И комментарии к 1 статье говорят, что поиск быстрее-таки в EAV https://t.me/pgsql/375892
Удобства в таких задачах вообще нет. Это боль) И на стороне бизнеса, где быстро появляются дубли классификаторов в разных ветках, тоже В вашем кейсе изменения так или иначе редки. Материализуйте всё, что можно
И да, логически этот поиск -- невеликая проблема. JOIN и JOIN, кого утомляют JOINы -- можэт суб-селект вписать, его оптимизатор в тожэ самое развернёт. Вот что делать с наборами атрибутов -- в смысле -- как это ускорить, чтобы реально раотало -- это другой вопрос. Но в постгресе есть довольно много всяких битмапоподобных и битмапообразующих индэксов, в цэлом какую-то комбинацыю на несчастный магазинчик с сотней тысяч товаров обычно можно подобрать так, чтобы частые запросы выполнялись быстро. Плюс, не упираться в единообразие. Самые частые свойства -- выносить таки в основные таблицы.
Не пойму, откуда дубли возьмутся. Есть список типов товаров (категорий). В них можно управлять свойствами. Когда создаёшь товар, выбираешь категорию. С сервера подтягивается список свойств. Заполняешь их - и сохраняешь товар
Дубли возьмутся от того, что ассортимент большой, товароведов/продактов много, а товарные линейки обновляются. Это не техническая проблема, впрочем
Сделать unique-ключ на связку <id категории товара>, <название свойства>. И тогда в рамках категории никаких дублей не будет, потому что их будет просто не создать
Обсуждают сегодня